Hello,

Jakub Jelinek <jakub@redhat.com> 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 COND_REDUCTION, but instead as former
> INTEGER_INDUC_COND_REDUCTION and just use a different constant instead of 0
> if 0 isn't usable for the condition never matched value.

While you could use values different from 0, I'm not sure this can be
done as efficiently.  0 is convenient because a single bitwise-and
between the index vector and the condition will set lanes that do not
contain a match to 0.

Jakub Jelinek <jakub@redhat.com> writes:
> First of all, I fail to see why we don't handle negative step,
> that can be done with REDUC_MIN instead of REDUC_MAX.

That would not work without first using values different from 0 to
indicate the absence of matches (except in cases where all indices are
negative), which I assume is why the test was there in the first place.

Below is the patch with fixed formatting and changes to make it apply
cleanly to r255537 (as far as I can tell this was simply caused by some
variables and constants having been renamed).

2017-11-21  Kilian Verhetsel  <kilian.verhetsel@uclouvain.be>

gcc/ChangeLog:
	PR testsuite/81179
	* 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 and
	check that no overflow will occur.

gcc/testsuite/ChangeLog:
	* gcc.dg/vect/vect-iv-cond-reduc-overflow-1.c: New test for
	overflows when compiling conditional reductions.
	* gcc.dg/vect/vect-iv-cond-reduc-overflow-2.c: Likewise.