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

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Nov 21, 2017 at 12:35 PM, Kilian Verhetsel
<kilian.verhetsel@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.verhetsel@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.
>