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

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

On Thu, 29 Aug 2019 at 13:27, Graham Hunter via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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 recognised.
Hi Graham,

I'm not a big fan of boolean flags on related concepts because the API
becomes brittle. In this case, BUILD_VECTOR-splat would need an assert
to make sure there's only one element.

Can we reuse the SPLAT_VECTOR node for predicated fixed width vectors?
This would simplify a bit the tail of the loop in AVX, for example,
but would also make sure we treat similar patterns in the same way,
and add to the list of reasons why to add a new node.

cheers,
--renato

Hi Renato,
> On 29 Aug 2019, at 14:00, Renato Golin <rengolin at gmail.com> wrote:
> 
> Hi Graham,
> 
> I'm not a big fan of boolean flags on related concepts because the API
> becomes brittle. In this case, BUILD_VECTOR-splat would need an assert
> to make sure there's only one element.
Ok.
> Can we reuse the SPLAT_VECTOR node for predicated fixed width vectors?
> This would simplify a bit the tail of the loop in AVX, for example,
> but would also make sure we treat similar patterns in the same way,
> and add to the list of reasons why to add a new node.
If we introduce the new node, I certainly expect it to be used for
fixed width vectors as well (though possibly not right away). Is there
anything special about predication in this use case, or is a simple
splat sufficient?

-Graham

On Thu, Aug 29, 2019 at 9:00 AM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Thu, 29 Aug 2019 at 13:27, Graham Hunter via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 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 recognised.
>
> Hi Graham,
>
> I'm not a big fan of boolean flags on related concepts because the API
> becomes brittle. In this case, BUILD_VECTOR-splat would need an assert
> to make sure there's only one element.
>
Agreed. #1 is better.

The Complex proposal requires special uses of broadcasts. Hopefully someone
from that project can comment here. It would be nice to design Complex
support into SPLAT_VECTOR, so that special lowerings aren't needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190829/d79e74c3/attachment.html>

On 8/29/19 7:26 AM, Graham Hunter via llvm-dev 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.

I believe that the new ISD node is the better design. It can default to 
Expand and the default expansion can fall back to the existing 
BUILD_VECTOR node (for fixed-length vectors). Thus, we can maintain 
backwards compatibility. Having a special flag on on BUILD_VECTOR that 
one needs to remember to check in order to know how to interpret the 
other node arguments seems prone to mistakes. In other words, we do 
already have a getSplatValue member on BuildVectorSDNode, and a number 
of other utility functions, but transforming those from utility 
functions to semantically-mandatory checks seems suboptimal.

  -Hal

>
> Any thoughts?
>
> -Graham
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

+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

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>