[llvm-dev] [SVE][AArch64] Codegen for a scalable vector splat

[Cameron McInally via llvm-dev]

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.
>
> Amara
>
> > 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
> prefers.
> >
> > 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
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=eIwz_I5be5PrK43j88xB5Sq6rozn9dgrd7VgeFkKkwM&s=yN2OEcjQuvdCMAhGa4lDVDxfYHUjQxhk-nfvMfoyYog&e=
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=eIwz_I5be5PrK43j88xB5Sq6rozn9dgrd7VgeFkKkwM&s=yN2OEcjQuvdCMAhGa4lDVDxfYHUjQxhk-nfvMfoyYog&e=
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190829/af10f7cc/attachment.html>