On Mon, 11 Dec 2017, Jakub Jelinek wrote:
> On Mon, Dec 11, 2017 at 06:00:11PM +0100, Kilian Verhetsel wrote:
> > Jakub Jelinek writes:
> > > Of course it can be done efficiently, what we care most is that the body
> > > of
> > > the vectorized loop is efficient.
> >
> >
On Mon, Dec 11, 2017 at 06:00:11PM +0100, Kilian Verhetsel wrote:
> Jakub Jelinek writes:
> > Of course it can be done efficiently, what we care most is that the body of
> > the vectorized loop is efficient.
>
> That's fair, I was looking at the x86 assembly being generated
Jakub Jelinek writes:
> Of course it can be done efficiently, what we care most is that the body of
> the vectorized loop is efficient.
That's fair, I was looking at the x86 assembly being generated when a single
vectorized iteration was enough (because that is the context in
On Mon, Dec 11, 2017 at 02:11:34PM +0100, Jakub Jelinek wrote:
> Thanks, it applies cleanly now
> > + else if ((STMT_VINFO_VEC_REDUCTION_TYPE (stmt_info) == COND_REDUCTION
> > + || (STMT_VINFO_VEC_REDUCTION_TYPE (stmt_info)
> > + == INTEGER_INDUC_COND_REDUCTION))
> > + &&
On Mon, Dec 11, 2017 at 11:56:55AM +0100, Kilian Verhetsel wrote:
> Jakub Jelinek writes:
> > As it doesn't apply, I can't easily check what the patch generates
> > on the PR80631 testcases vs. my thoughts on that; though, if it emits
> > something more complicated for the
Hello,
Jakub Jelinek writes:
> As it doesn't apply, I can't easily check what the patch generates
> on the PR80631 testcases vs. my thoughts on that; though, if it emits
> something more complicated for the simple cases, perhaps we could improve
> those (not handle it like
Hi!
What is going on with this patch, will anybody commit it?
This is also http://gcc.gnu.org/PR80631 apparently.
The patch doesn't apply cleanly to current trunk due to the
reduc_code -> reduc_fn changes.
As it doesn't apply, I can't easily check what the patch generates
on the PR80631
On Thu, Nov 23, 2017 at 10:51 AM, Alan Hayward wrote:
>
>> On 22 Nov 2017, at 16:57, Kilian Verhetsel
>> wrote:
>>
>>
>> Thank you both for your comments.
>>
>> I have added the check to ensure the index vector won't cause an
>> overflow. I
> On 22 Nov 2017, at 16:57, Kilian Verhetsel
> wrote:
>
>
> Thank you both for your comments.
>
> I have added the check to ensure the index vector won't cause an
> overflow. I also added tests to the testsuite in order to check that the
> loop is vectorized
Thank you both for your comments.
I have added the check to ensure the index vector won't cause an
overflow. I also added tests to the testsuite in order to check that the
loop is vectorized for UINT_MAX - 1 iterations but not UINT_MAX
iterations. I was not able to write code that triggers
On Wed, Nov 22, 2017 at 12:01 PM, Alan Hayward wrote:
>
>> On 22 Nov 2017, at 09:14, Richard Biener wrote:
>>
>> On Tue, Nov 21, 2017 at 5:43 PM, Kilian Verhetsel
>> wrote:
>>>
This is PR81179 I think, please
> On 22 Nov 2017, at 09:14, Richard Biener wrote:
>
> On Tue, Nov 21, 2017 at 5:43 PM, Kilian Verhetsel
> wrote:
>>
>>> This is PR81179 I think, please mention that in the changelog.
>>
>> Correct, my bad for missing that.
>>
>>>
On Tue, Nov 21, 2017 at 5:43 PM, Kilian Verhetsel
wrote:
>
>> This is PR81179 I think, please mention that in the changelog.
>
> Correct, my bad for missing that.
>
>> This unconditionally pessimizes code even if there is no valid index
>> zero, right?
>
> Almost,
> On 21 Nov 2017, at 16:43, Kilian Verhetsel
> wrote:
>
>
>> This is PR81179 I think, please mention that in the changelog.
>
> Correct, my bad for missing that.
>
>> This unconditionally pessimizes code even if there is no valid index
>> zero, right?
>
>
> This is PR81179 I think, please mention that in the changelog.
Correct, my bad for missing that.
> This unconditionally pessimizes code even if there is no valid index
> zero, right?
Almost, since for a loop such as:
#define OFFSET 1
unsigned int find(const unsigned int *a, unsigned int
On Tue, Nov 21, 2017 at 12:35 PM, Kilian Verhetsel
wrote:
>
> Hi,
>
> When translating conditional reductions based on integer induction, the
> compiler uses the value zero to indicate the absence of any matches: if
> the index of the last match is still zero at the
16 matches
Mail list logo