How should we handle matrix ABIs?

[workingjubilee]

Some CPU architectures have developed "matrix extensions". These are sometimes equivalent to "vectors, but bigger" in terms of how the ABI should be handled (reusing the same architectural state, thus having similar concerns). But not always! They may use entirely different architectural state, usually entirely "caller-save" (i.e. always "volatile" or "call-clobbered").

AArch64

Scalable Matrix Extensions

• https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-scalable-matrix-extension-introduction
• How should we handle dynamic vector ABIs? #133146

PowerPC

MMA

• Figure out which target features are required for which SIMD size #131800 (comment)

x86

AMX

• Tracking Issue for x86_amx_intrinsics #126622
• introduces the amx_tile type, AKA x86_amx or __tile1024i

References

• Figure out which target features are required for which SIMD size #131800

[programmerjake]

afaik PowerPC MMA doesn't change the ABI: #131800 (comment)

[workingjubilee]

It is good this issue is about handling ABIs rather than merely describing them, then? specifically, if we want to avoid involving this in our ABIs, we need to adopt the same bans.

[RalfJung]

How does LLVM even represent these types in function signatures?

Sounds to me like this will require repr(matrix) and corresponding dedicated logic everywhere?