on 2022/6/20 15:47, Richard Biener wrote:
> On Fri, Jun 17, 2022 at 12:53 PM Kewen.Lin <li...@linux.ibm.com> wrote:
>>
>> Hi,
>>
>> This follows Richi's suggestion in PR105940, it aims to avoid
>> inconsistent slp decision between when the suggested unroll
>> factor is worked out and when the suggested unroll factor is
>> applied.
>>
>> If the previous slp decision is true when the suggested unroll
>> factor is worked out, when we are applying unroll factor we
>> don't need to start over with slp off if the analysis with slp
>> on fails. On the other hand, if the previous slp decision is
>> false when the suggested unroll factor is worked out, when we
>> are applying unroll factor we can skip the slp handlings.
>>
>> Function vect_is_simple_reduction saves reduction chains for
>> subsequent slp analyses, we have to disable this early otherwise
>> there is an ICE in vectorizable_reduction for below:
>>
>> if (REDUC_GROUP_FIRST_ELEMENT (stmt_info))
>> gcc_assert (slp_node
>> && REDUC_GROUP_FIRST_ELEMENT (stmt_info)
>> == stmt_info);
>
> We ensure this by either decomposing the group in vect_analyze_slp
> if the reduction chain doesn't SLP or when we re-try without SLP
> by not re-trying:
>
> /* If there are reduction chains re-trying will fail anyway. */
> if (! LOOP_VINFO_REDUCTION_CHAINS (loop_vinfo).is_empty ())
> return ok;
>
Yeah, thanks for the pointer. I put one alternative in the PR using
the undo (decomposing) way in vect_analyze_loop_2, but thought passing
slp flag down looks better as we avoid the useless efforts.
>> Bootstrapped and regtested on x86_64-redhat-linux,
>> powerpc64{,le}-linux-gnu and aarch64-linux-gnu.
>>
>> Also tested with SPEC2017 build with some rs6000 hacking.
>>
>> Is it ok for trunk?
>
> OK.
>
Thanks Richi! Committed as r13-1173.
BR,
Kewen
