On Mon, 6 Nov 2023, Andrew Stubbs wrote:
>
>
> On 06/11/2023 07:52, Richard Biener wrote:
> > On Fri, 3 Nov 2023, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
> >> The current codegen code to support VF's that are multiples of a simdclone
> >> simdlen rely on BIT_FIELD_REF to create multiple input vectors. This does
> >> not
> >> work for non-constant simdclones, so we should disable using such clones
> >> when
> >> the VF is a multiple of the non-constant simdlen until we change the
> >> codegen
> >> to support those.
> >>
> >> Enabling SVE simdclone support will cause ICEs if the vectorizer decides to
> >> use a SVE simdclone with a VF that is larger than the simdlen. I'll be away
> >> for the next two weeks, so cant' really discuss this further.
> >> I initially tried to solve the problem, but the way
> >> vectorizable_simd_clone_call is structured doesn't make it easy to replace
> >> BIT_FIELD_REF with the poly-suitable solution right now of using
> >> unpack_{hi,lo}.
> >
> > I think it should be straight-forward to use unpack_{even,odd} (it's
> > even/odd for VLA, right? If lo/hi would be possible then doing
> > BIT_FIELD_REF would be, too? Also you need to have multiple stages
> > of unpack/pack when the factor is more than 2).
> >
> > There's plenty of time even during stage3 to address this.
> >
> > At least your patch should have come with a testcase (or two).
> >
> > Is there a bugreport tracking this issue? It should affect GCN as well
> > I guess.
>
> What does "non-constant simdclones" mean? I'm not sure if this is a thing that
> can happen on GCN, or not?
simdclone with a variable (POLY_INT) vector size.
Richard.
