On Tue, Nov 21, 2017 at 12:35 PM, Kilian Verhetsel <kilian.verhet...@uclouvain.be> 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 end of the loop, the > default value is returned. The problem with this approach is that this > default value is returned not only when there were no matches at all, > but also when the last match occurred at index 0. This causes the test > gcc.dg/vect/pr65947-14.c to fail. > > This patch corrects this by reusing the vector of indices used for > COND_REDUCTION, which starts at 1. If the 1-based index of the last > match is non-zero, 1 is subtracted from it, otherwise the initial value > is returned. > > I tested this patch on x86_64-pc-linux-gnu (both with SSE and AVX2, > causing both paths through the reduc_code != ERROR_MARK branch being > taken).
This is PR81179 I think, please mention that in the changelog. This unconditionally pessimizes code even if there is no valid index zero, right? The issue with the COND_REDUCITION index vector is overflow IIRC. Alan, can you please comment on the patch? Thanks, Richard. > 2017-11-21 Kilian Verhetsel <kilian.verhet...@uclouvain.be> > > * tree-vect-loop.c > (vect_create_epilog_for_reduction): Fix the returned value for > INTEGER_INDUC_COND_REDUCTION whose last match occurred at > index 0. > (vectorizable_reduction): For INTEGER_INDUC_COND_REDUCTION, > pass the PHI statement that sets the induction variable to the > code generating the epilogue. >