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

[Sander De Smalen via llvm-dev]

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