On Thu, 10 Jul 2025, Tamar Christina wrote:
> > -----Original Message-----
> > From: Richard Biener <rguent...@suse.de>
> > Sent: Thursday, July 10, 2025 6:42 PM
> > To: Tamar Christina <tamar.christ...@arm.com>
> > Cc: gcc-patches@gcc.gnu.org; Richard Sandiford <richard.sandif...@arm.com>;
> > CI RISC-V <patchworks...@rivosinc.com>
> > Subject: Re: [PATCH] Reject single lane vector types for SLP build
> >
> >
> >
> > > 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.
>
> Yeah, mixed sized vectors will be a challenge, they weren't on my list for
> now, neither is VLA, or even VLS, the problem is that for at least SVE, many
> of the
> control structures are opague. So niters has no clue, DF analysis doesn't
> know about
> the loads etc.
>
> So VLA and SVE general as an input is a bit further out.
>
> >
> > 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.
> >
>
> Hmm so is the idea to treat them as supported for the purpose of
> vectorizations
> and then decompose them during codegen? Do we not run the risk then of
> potentially missing out on other passes ending up making the operation
> supported?
Vectorization takes existing vectors just as another way to encode the
scalar instruction flow, so it shouldn't matter to it whether the
operations use a vector mode and are supported or whether they are
BLKmode or unsupported. But the vectorization result would be of course
supported. Iff (re-)vectorization fails we'd have a SLP instance we
can scalarize - and we are in a better position to do this sensibly
than the current vector lowering pass which works stmt-by-stmt.
Richard.
> Cheers,
> Tamar
>
> > 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)
>
--
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)
