Hello everyone. With the rapid growth of AI computing power, LLVM appears to be insufficient in terms of backend support for some proprietary computing chips. For example:
Encoding and decoding of some instructions with large bit counts;
Matrix multiplication, the most common operation in AI computing, lacks an IR representation.
Is the community interested in introducing architectural support for generalized AI compilation?
Would you elaborate on this item a bit? That is, is this a limitation you’ve seen in the past or even now? What are the characteristics of the encodings?
In the past, there were certainly a number of defects regarding decoding and encoding of large (i.e., greater than 64 bits) instructions, but much of that has been corrected. Our downstream production LLVM backend successfully targets a complicated ISA with encodings of up to 384 bits. There are also a couple of other downstream targets using long encodings.
But it would not be surprising if some problems persist. If you are still encountering encoding/decoding problems, please post an issue GitHub · Where software is built and mention here.
This item justifies an entire discussion of its own. You might mention “representation of matrix multiplication” somewhere in the title– I’m sure you’ll get more than a few comments.
I have encountered extreme instruction encodings of 4000+ bits, which I solved by custom modifying tablegen. I appreciate the efforts of the contributors. I know that llvm currently supports instruction encodings larger than 64 bits, but long instructions mean that MClayer cannot efficiently match MachineIR patterns (perhaps I have not found an effective way).
This is indeed a topic that can be discussed separately. Thank you for your reply.
For matrix multiplication operation , many solutions I know nowadays lower high-level representation of matmul – MLIR for example – directly to target-specific intrinsics. But of course that’s just half of the story: sometimes we want an effective way to represent matrix types, especially for targets that have native “matrix registers”. In that case perhaps TargetExtType could help: LLVM: llvm::TargetExtType Class Reference