Re: [PATCH] Fix result for conditional reductions matching at index 0 (PR tree-optimization/80631)

2017-12-11 Thread Richard Biener
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. > > > >

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-12-11 Thread Jakub Jelinek
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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-12-11 Thread Kilian Verhetsel
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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-12-11 Thread Jakub Jelinek
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)) > > + &&

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-12-11 Thread Jakub Jelinek
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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-12-11 Thread Kilian Verhetsel
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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-12-08 Thread Jakub Jelinek
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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-11-23 Thread Richard Biener
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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-11-23 Thread Alan Hayward
> 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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-11-22 Thread Kilian Verhetsel
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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-11-22 Thread Richard Biener
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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-11-22 Thread Alan Hayward
> 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. >> >>>

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-11-22 Thread Richard Biener
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,

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-11-21 Thread Alan Hayward
> 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? > >

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-11-21 Thread Kilian Verhetsel
> 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

Re: [PATCH] Fix result for conditional reductions matching at index 0

2017-11-21 Thread Richard Biener
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