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

[Amara Emerson via llvm-dev]

+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://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev