[llvm-dev] [RFC] Inline asm constraint & operand modifier for data512_t

Alexandros Lamprineas via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 23 16:20:56 PST 2020


Hello list,

The AArch64 Armv8.7-A LD64B/ST64B Accelerator extension is ready to land [1]. The latest Arm ACLE [2] introduces a data type for intrinsic support of the load/store instructions of this extension. The type is defined as `typedef struct { uint64_t val[8]; } data512_t;` in ยง8.9 - Load/store 64 Byte intrinsics. We would like this type to be supported for inline assembly as well. The basic problem is to determine what is the right type to represent this in LLVM IR and then what is the Machine Value type this maps to before we finally lower it to the GPR64x8 register class [3]. It has to be a single data item, which means it must have a type that's 64 bytes / 512 bits large.

An obvious choice is i512, but there is no Machine Value type for it. The integer types in LLVM's enumeration of 'simple value types' only go up to i128, which means both i512 and i256 need to be added because most of the legalization / lowering machinery for integer types assumes that you can find an integer type half the size. But can we legalize those types? The i256 value type doesn't even have a register class to begin with. Even if we manage to just legalize i512 for loads and stores it's not enough. Legitimate IR, which performs arithmetic on i512, would make the compiler crash during instruction selection in the absence of i256.

Another idea was to use an array of [8 x i64], but this maps to MVT::Other which isn't specific enough to be dealt by the backend.

I think that it's not right to use any of the existing LLVM IR types, which leaves us with inventing a new one. Any thoughts on this?

Kind regards,
Alexandros

[1] https://reviews.llvm.org/D91775
[2] https://developer.arm.com/documentation/101028/latest
[3] https://reviews.llvm.org/D91774

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201124/f800dfdd/attachment.html>


More information about the llvm-dev mailing list