> Am 10.07.2025 um 16:27 schrieb Tamar Christina <tamar.christ...@arm.com>:
>
>
>>
>> -----Original Message-----
>> From: Richard Biener <rguent...@suse.de>
>> Sent: Thursday, July 10, 2025 3:09 PM
>> To: Tamar Christina <tamar.christ...@arm.com>
>> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford <richard.sandif...@arm.com>;
>> RISC-V CI <patchworks...@rivosinc.com>
>> Subject: RE: [PATCH] Reject single lane vector types for SLP build
>>
>> On Thu, 10 Jul 2025, Tamar Christina wrote:
>>
>>>> -----Original Message-----
>>>> From: Richard Biener <rguent...@suse.de>
>>>> Sent: Thursday, July 10, 2025 1:31 PM
>>>> To: gcc-patches@gcc.gnu.org
>>>> Cc: Richard Sandiford <richard.sandif...@arm.com>; Tamar Christina
>>>> <tamar.christ...@arm.com>; RISC-V CI <patchworks...@rivosinc.com>
>>>> Subject: [PATCH] Reject single lane vector types for SLP build
>>>>
>>>> The following makes us never consider vector(1) T types for
>>>> vectorization and ensures this during SLP build. This is a
>>>> long-standing issue for BB vectorization and when we remove
>>>> early loop vector type setting we lose the single place we have
>>>> that rejects this for loops.
>>>>
>>>> Once we implement partial loop vectorization we should revisit
>>>> this, but then use the original scalar types for the unvectorized
>>>> parts.
>>>
>>> SGTM FWIW,
>>>
>>> I was also wondering if I should start upstreaming my changes to
>>> get the vectorizer to recognize vector types as scalar types as well.
>>>
>>> Or if you wanted me to wait until I have the lane representations
>>> more figured out.
>>
>> I think if we can restrict things to cases that have a strong
>> overlap with what we intend to use in the end that sounds good.
>> Like allow only a single "scalar" vector def per SLP node for now
>> and simply stash that into the scalar-stmts array. In the end
>> we'd want to allow mixed scalar and vector defs there.
>
> At least for my use case I'd need to be able to do multiple "scalar"
> vector lanes, but restricted to the same size for each lane is fine for
> now.
>
> But I don't think where's actually much difference here between
> one "scalar" and multiple "scalars" representations wise now is there?
Not if they are at least uniform, not mixed vector ns scalar or different
vector sizes.
What’s going to be interesting (or impossible?) might be VLA vectors.
But I’d like to see the BB vectorizer deal with vector lowering, so each target
unsupported vector stmt would be a BB vect seed.
Richard
>
> Thanks,
> Tamar
>
>>
>> It does require altering code that expects to get at actual _scalar_
>> defs for each lane, but I don't think that's much code.
>>
>> Richard.
>>
>>> Regards,
>>> Tamar
>>>>
>>>> Bootstrapped and tested on x86_64-unknown-linux-gnu. I'll see
>>>> if there's any surprises from the CI, but otherwise I'll go
>>>> ahead with this.
>>>>
>>>> Richard.
>>>>
>>>> * tree-vect-slp.cc (vect_build_slp_tree_1): Reject
>>>> single-lane vector types.
>>>> ---
>>>> gcc/tree-vect-slp.cc | 9 +++++++++
>>>> 1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
>>>> index ad75386926a..d2ce4ffaa4f 100644
>>>> --- a/gcc/tree-vect-slp.cc
>>>> +++ b/gcc/tree-vect-slp.cc
>>>> @@ -1114,6 +1114,15 @@ vect_build_slp_tree_1 (vec_info *vinfo, unsigned
>> char
>>>> *swap,
>>>> matches[0] = false;
>>>> return false;
>>>> }
>>>> + if (known_le (TYPE_VECTOR_SUBPARTS (vectype), 1U))
>>>> + {
>>>> + if (dump_enabled_p ())
>>>> + dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>>>> + "Build SLP failed: not using single lane "
>>>> + "vector type %T\n", vectype);
>>>> + matches[0] = false;
>>>> + return false;
>>>> + }
>>>> /* Record nunits required but continue analysis, producing matches[]
>>>> as if nunits was not an issue. This allows splitting of groups
>>>> to happen. */
>>>> --
>>>> 2.43.0
>>>
>>
>> --
>> Richard Biener <rguent...@suse.de>
>> SUSE Software Solutions Germany GmbH,
>> Frankenstrasse 146, 90461 Nuernberg, Germany;
>> GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)