[LLVM][SVE] Honour calling convention when using SVE for fixed length vectors.

[paulwalker-arm]

NOTE: I'm not sure how many of the corner cases are part of the documented ABI but that shouldn't matter because my goal is for -msve-vector-bits to have no affect on the way arguments and returns are processed.

NOTE: I'm forming an idea as to whether this means we can potentially enable fixed length predicate types because my main blocking concern was not wanting to change the existing calling convention surrounding those types.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[paulwalker-arm]

Just a rebase, I still need to add tests.

[vfdff]

hi @paulwalker-arm , If we still prefer the NEON regitster, can we just ignore to addRegisterClass for these fix registers, whose vector length is bigger than 128-bit?

llvm-project/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp

Line 413 in 0016565

if (Subtarget->useSVEForFixedLengthVectors()) {

[paulwalker-arm]

hi @paulwalker-arm , If we still prefer the NEON regitster, can we just ignore to addRegisterClass for these fix registers, whose vector length is bigger than 128-bit?

llvm-project/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp

Line 413 in 0016565

if (Subtarget->useSVEForFixedLengthVectors()) {

No because we still want such types to be legal so that in function code generation can use them. This patch just ensures that at function call boundaries the "legal" types are restricted to those which are defined by an ABI.

I've also started thinking about whether this scheme means I can also make fixed length i1 vectors legal so that we can make better use of the predicate registers because there's a few cases where force extending them to i8 vectors causes pretty bad code. This is especially true when crossing basic block boundaries.

[vfdff]

hi @paulwalker-arm , If we still prefer the NEON regitster, can we just ignore to addRegisterClass for these fix registers, whose vector length is bigger than 128-bit?

llvm-project/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp

Line 413 in 0016565

if (Subtarget->useSVEForFixedLengthVectors()) {

No because we still want such types to be legal so that in function code generation can use them. This patch just ensures that at function call boundaries the "legal" types are restricted to those which are defined by an ABI.

I've also started thinking about whether this scheme means I can also make fixed length i1 vectors legal so that we can make better use of the predicate registers because there's a few cases where force extending them to i8 vectors causes pretty bad code. This is especially true when crossing basic block boundaries.

thanks very much for your explaination :)

[paulwalker-arm]

• Rebased.
• Finalised the support by matching the behaviour for types that should result in scalarisation.
• Added tests.

[paulwalker-arm]

To aid review I've split the tests into a separate patch, albeit they don't show the existing broken output because many of the tests trigger internal compiler errors and the existing output does not really matter because it's wrong.

[davemgreen]

I agree this sounds like the right direction to take. We probably cant get away with not supporting these argument types with fixed length SVE, and it sounds best to not change the ABI based on having the target feature and sve min vector width.

This seems to mark scalar variables as being passed in gpr registers, where as they should be the first element in a wider vector. See AArch64TargetLowering::getPreferredVectorAction for where it is overridden.

[paulwalker-arm]

This seems to mark scalar variables as being passed in gpr registers, where as they should be the first element in a wider vector. See AArch64TargetLowering::getPreferredVectorAction for where it is overridden.

Thanks for the info. This comes from the base version of getVectorTypeBreakdown. However, this gets bypassed for simple EVTs so it looks like I'll need special handing for scalar vectors as well.

[paulwalker-arm]

Fallback to calling base versions of getRegisterTypeForCallingConv and getNumRegistersForCallingConv for unit-length vectors. Extended testing to cover unit-length vectors.

[davemgreen]

Thanks. From what I can tell this LGTM.