> Am 14.09.2024 um 11:38 schrieb Robin Dapp <rdapp....@gmail.com>:
>
>
>>
>> The following simply removes a seemingly bogus guard.
>>
>> * tree-vect-loop.cc (vect_analyze_loop_1): Remove SLP guard
>> from .SELECT_VL disabling.
>> ---
>> gcc/tree-vect-loop.cc | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
>> index cc15492f6a0..378e7c560bd 100644
>> --- a/gcc/tree-vect-loop.cc
>> +++ b/gcc/tree-vect-loop.cc
>> @@ -3078,7 +3078,7 @@ start_over:
>> if (direct_internal_fn_supported_p (IFN_SELECT_VL, iv_type,
>> OPTIMIZE_FOR_SPEED)
>> && LOOP_VINFO_LENS (loop_vinfo).length () == 1
>> - && LOOP_VINFO_LENS (loop_vinfo)[0].factor == 1 && !slp
>> + && LOOP_VINFO_LENS (loop_vinfo)[0].factor == 1
>
> I don't think it will just work like that. The problem is that we adjust data
> pointer increments according to the current vector length in
> vect_get_loop_variant_data_ptr_increment.
>
> To this end we use the SELECT_VL result and multiply it with the current
> dataref's step. Without having looked into it closer I suppose using step is
> not suffcient or maybe even wrong in an SLP setting and I guess this
> complication lead to SLP being disabled initially.
Yes, that’s one complication. Another is that the length would need to be
scaled by the SLP group size - but maybe one could use lmul for that…
(assuming an uniform loop)
Restricting SLP to the case of all single-lane nodes should work though.
Richard.
> --
> Regards
> Robin
>
