llvm dev - Jun 2020 - [AArch64][SVE] Floating Point Code Gen

Hello,

I am following up on the issue discussed at the SVE meeting, Sander
mentioned that there were some patterns missing from SVE CodeGen for
floating point operations, but I was unable to identify them.

He mentioned something about looking at the ISelLowering for AArch64 to
identify them, so if there is any information of that regard it would be
greatly appreciated so we can contribute with the missing patterns that
will be required later on when fixed-width vectors are implemented.

Best regards,
Danilo Carvalho Grael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200615/df8a7033/attachment.html>

Hi Danilo,

Thanks for following this up.

The IR instructions to codegen are unpredicated, where most SVE instructions are
predicated, so in D71712 you can see we've had to patterns that map these
nodes to predicated instructions (see for example defm:
unpred_from_pred_one_op_fp<fabs, ...>). In trunk we don't really want
to solve it the same way as in D71712, because we'd rather generate the
predicate patterns in ISelLowering by custom lowering the operation to an
AArch64ISD node that takes a predicate. This way the patterns themselves are
trivial and we don't need to add new patterns when adding codegen for
fixed-width vectors (these will use the same patterns, same types and the same
AArch64ISD nodes, but a different predicate value). The patterns to add are for
the following types:
- nxv2f16, nxv4f16, nxv8f16
- nxv2f32, nxv4f32
- nxv2f64

We've already done this type of custom lowering for several nodes, see for
example the uses of `AArch64TargetLowering::LowerToPredicatedOp()` in trunk.

For illegal vectors there will also some work needed for the code that legalizes
illegal types. For example, SplitVecOp_FP_ROUND currently drops the
'scalable' flag of the result vector when it tries to legalize it. There
may be other cases like this as well.

A good starting point is probably the patterns we've added for the FP nodes
in D71712 if you search for `unpred_from_pred_.*_fp`.

Hope that helps!

Cheers,

Sander
> On 15 Jun 2020, at 19:53, Danilo Carvalho Grael <dancgr at gmail.com>
wrote:
> 
> Hello,
> 
> I am following up on the issue discussed at the SVE meeting, Sander
mentioned that there were some patterns missing from SVE CodeGen for floating
point operations, but I was unable to identify them.
> 
> He mentioned something about looking at the ISelLowering for AArch64 to
identify them, so if there is any information of that regard it would be greatly
appreciated so we can contribute with the missing patterns that will be required
later on when fixed-width vectors are implemented.
> 
> Best regards,
> Danilo Carvalho Grael

Thanks Sander,

That is exactly what I needed! We will be working on a few patches for
those patterns.

Best regards,
Danilo Carvalho Grael


On Tue, Jun 16, 2020 at 11:30 AM Sander De Smalen <Sander.DeSmalen at
arm.com>
wrote:
> Hi Danilo,
>
> Thanks for following this up.
>
> The IR instructions to codegen are unpredicated, where most SVE
> instructions are predicated, so in D71712 you can see we've had to
patterns
> that map these nodes to predicated instructions (see for example defm:
> unpred_from_pred_one_op_fp<fabs, ...>). In trunk we don't really
want to
> solve it the same way as in D71712, because we'd rather generate the
> predicate patterns in ISelLowering by custom lowering the operation to an
> AArch64ISD node that takes a predicate. This way the patterns themselves
> are trivial and we don't need to add new patterns when adding codegen
for
> fixed-width vectors (these will use the same patterns, same types and the
> same AArch64ISD nodes, but a different predicate value). The patterns to
> add are for the following types:
> - nxv2f16, nxv4f16, nxv8f16
> - nxv2f32, nxv4f32
> - nxv2f64
>
> We've already done this type of custom lowering for several nodes, see
for
> example the uses of `AArch64TargetLowering::LowerToPredicatedOp()` in
trunk.
>
> For illegal vectors there will also some work needed for the code that
> legalizes illegal types. For example, SplitVecOp_FP_ROUND currently drops
> the 'scalable' flag of the result vector when it tries to legalize
it.
> There may be other cases like this as well.
>
> A good starting point is probably the patterns we've added for the FP
> nodes in D71712 if you search for `unpred_from_pred_.*_fp`.
>
> Hope that helps!
>
> Cheers,
>
> Sander
> > On 15 Jun 2020, at 19:53, Danilo Carvalho Grael <dancgr at
gmail.com>
> wrote:
> >
> > Hello,
> >
> > I am following up on the issue discussed at the SVE meeting, Sander
> mentioned that there were some patterns missing from SVE CodeGen for
> floating point operations, but I was unable to identify them.
> >
> > He mentioned something about looking at the ISelLowering for AArch64
to
> identify them, so if there is any information of that regard it would be
> greatly appreciated so we can contribute with the missing patterns that
> will be required later on when fixed-width vectors are implemented.
> >
> > Best regards,
> > Danilo Carvalho Grael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200622/f6e85662/attachment.html>