[llvm-dev] [RFC] Extending shufflevector for vscale vectors (SVE etc.)

Nicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Sun Feb 2 00:57:31 PST 2020


Hi Renato,

On Thu, Jan 30, 2020 at 9:56 AM Renato Golin <rengolin at gmail.com> wrote:
> On Thu, 30 Jan 2020 at 08:22, Nicolai Hähnle via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > This fixed list of shuffles makes me uncomfortable, and I wonder if
> > there isn't a much simpler solution to the problem. Specifically,
> > allow the IR form:
> >
> > %result = shufflevector <vscale x n x TY> %v1, <vscale x n x TY> %v2,
> > <m x i32> <mask>
> >
> > yielding a result of type <vscale x m x TY>. (The <mask> could still
> > just be a constant list of integers, i.e. this doesn't require a
> > relaxation to arbitrary Value* masks.)
>
> Back when Arm was proposing the SVE extensions, another proposal was
> to use SCEV like patterns.
>
> I think they're all valid proposals, but implementation wise, they can
> get really complicated.
>
> Masks and expressions will have to be pattern-matched against
> target-specific instructions when lowering, and if we're not going to
> be generating the most unusual patterns to begin with
> (front-end/middle-end creating them), then I think a fixed list to
> begin with is quite sensible.
>
> For example, I wouldn't want to let the vectoriser generate any random
> pattern in the shuffle if I know that there is no valid instruction in
> the back-end that can cope with that, and I'll end up with
> under-performing code.

How is any of this different from non-vscale shufflevector?

It feels to me that if you're not willing to do a natural extension of
what's in shufflevector already, then going with an intrinsic for the
time being is the wiser choice.

Cheers,
Nicolai


> A fixed list will also allow us to build the infrastructure first,
> with one less problem to handle. After we're sure it works well, we
> can extend to different patterns.
>
> For example, we can add to SHUFFLE-NAME things like "mask" and "scev"
> and "expr", and then add whatever to the end of it. In those edge
> cases, it will be up to the back-end to legalise that in a meaningful,
> and hopefully performing, way.
>
> cheers,
> --renato



-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.


More information about the llvm-dev mailing list