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).
2017-11-21 Kilian Verhetsel
* tree-vect-loop.c
> 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
d for
COND_REDUCTION) in the branch of code run only for COND_REDUCTION, this
should remove the unused vector that Alan noticed.
2017-11-21 Kilian Verhetsel
gcc/ChangeLog:
PR testsuite/81179
* tree-vect-loop.c
(vect_create_epilog_for_reduction): Fix the returned valu
tell this was simply caused by some
variables and constants having been renamed).
2017-11-21 Kilian Verhetsel
gcc/ChangeLog:
PR testsuite/81179
* tree-vect-loop.c (vect_create_epilog_for_reduction): Fix the
returned value for INTEGER_INDUC_COND_REDUC
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 which I
first encou
