[llvm-dev] [SVE][AArch64] Codegen for a scalable vector splat
Cameron McInally via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 29 16:23:45 PDT 2019
Just spitballing... why not have a splat construct straight through LLVM?
It would make the IR more readable, opposed to the insert+shuffle method.
On Thu, Aug 29, 2019 at 19:06 Amara Emerson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +1 to a new node, we’d very likely do the same thing for GlobalISel and
> move to a canonical spat representation for all targets.
> > On Aug 29, 2019, at 5:26 AM, Graham Hunter via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > Hi,
> > During the discussion on introducing scalable vectors we established
> that we could use the canonical IR form for splats of scalable vector types
> (insert element into lane 0 of an undef vector, shuffle that with another
> undef vector of the same type and a zeroinitializer mask).
> > We do run into a problem for lowering to SelectionDAG however, since the
> canonical form there is a BUILD_VECTOR with all elements being the same.
> This obviously doesn't work if we don't know how many elements there are.
> We have a couple of solutions and would like to know which the community
> > 1) Add a new SPLAT_VECTOR ISD node. This was part of our overall RFC
> from 2016 and is the solution that we're currently using downstream. It
> just accepts a single scalar value. This has worked well with just the SVE
> codegen using it, but I don't know if we would run into problems if we try
> to make this the canonical splat form for SDAG.
> > 2) Extend BUILD_VECTOR to accept an initial boolean indicating whether
> it is a splat, and if true the first element can be assumed to be the same
> as all others. The splat form would be the only valid use of BUILD_VECTOR
> for scalable vector types. For fixed length vectors we could either change
> existing checks for splats to only look at the flag and would only need one
> extra argument for the splat value, or use the flag as a shortcut and fall
> back to checking all the elements if there's the possibility of a fold
> generating a splat and it not being recognized.
> > Given the existence of MVTs with >1000 elements per vector, the
> SPLAT_VECTOR or BUILD_VECTOR with single element approach may also be
> beneficial for some fixed length backends.
> > Any thoughts?
> > -Graham
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev