Twice (Nov 16 2024 at 17:24): Twice (Nov 16 2024 at 17:24):Hello everyone, I am working on GPU/AI compilers and have a strong interest in cranelift.
The idea of multi-layer IR and progressive lowering is gaining attention due to the popularity of MLIR. Compared to previous approaches to put LLVM IR (or cranelift IR) as the central IR, multi-layer IR often improves engineering efficiency and maintainability by gradually breaking down structured semantics. In the AI ecosystem, MLIR is becoming increasingly crucial as many frameworks like TensorFlow, XLA, Triton, JAX, IREE use it for their compilation toolchains. Additionally, MLIR is making significant contributions to traditional compilers such as flang and clangir, as well as circuit compilers like CIRCT.
While I know that MLIR has Rust bindings, I wonder if having a native multi-layer IR compiler infrastructure within the Rust ecosystem, with close integrating of cranelift IR as a backend IR, could simplify developing any (CPU/GPU/AI/..) compilers using Rust. And I wonder if we could create a new project for this purpose, how would such a framework be different from MLIR? How would it be designed based on Rust's features? Also since rustc itself is based on multi-level lowering, any chance we can find from it about how we can simplify construction of these compilers?
Sorry this might be off-topic but I believe people in the cranelift community may find this interesting and give some suggestions.
bjorn3 (Nov 17 2024 at 12:25):MLIR wouldn't benefit Cranelift or Wasmtime. It would only add compile time overhead and if you want the best runtime performance you already should be using LLVM instead. Rustc wouldn't benefit from replacing any of it's internal IR's with MLIR either as MLIR it closely tied with the LLVM ecosystem AFAIK while rustc needs to support backends for GCC and Cranelift too. In addition rustc needs a whole lot of custom serialization logic for serializing things into the crate metadata and incr comp cache and in both cases it needs to be possible to deserialize (part of the data for) a single function at a time, while I think MLIR requires deserializing a whole module at once. The MLIR C api (which rustc would need to use as calling C++ api's would need a wrapper exposing a C api) is also unstable.
Twice (Nov 17 2024 at 13:07):Hmm.. if what you are referring to as MLIR is the subproject in LLVM, I think this may not be relevant to my proposal: I did not intend to use MLIR to replace anything. My idea is to provide a reusable compiler infrastructure (written in Rust) that can be used in many different compilers to save development time (instead of just a low-level IR like LLVM/cranelift IR). And this infrastructure may closely resemble the design of MLIR (or it may have many differences, which is exactly what I hope to discuss).
Also you mentioned that "as MLIR it closely tied with the LLVM ecosystem", and I think it's one of the reasons why a (multi-level) compiler infrastructure in Rust ecosystem tied to cranelift (and maybe also LLVM/SPIRV..) would have potential benefits.
Twice (Nov 17 2024 at 13:29):In addition, from my understanding of MLIR, the target IR of MLIR is not necessarily LLVM IR. Currently, in addition to LLVM IR, MLIR can target to SPIRV and C++ code (if you want to add a new target IR, just add a new "dialect" to MLIR and provide some "conversion" patterns/passes).
You also mentioned incremental compilation, which is something I am interested in. If we can have a good design of the compiler framework/infrastruture that allows users to easily support incremental compilation, it can also reduce a lot of work (such as serialization, as you mentioned).
Nihal Pasham (Nov 17 2024 at 15:30):Twice said:
While I know that MLIR has Rust bindings, I wonder if having a native multi-layer IR compiler infrastructure within the Rust ecosystem, with close integrating of cranelift IR as a backend IR, could simplify developing any (CPU/GPU/AI/..) compilers using Rust. And I wonder if we could create a new project for this purpose, how would such a framework be different from MLIR? How would it be designed based on Rust's features? Also since rustc itself is based on multi-level lowering, any chance we can find from it about how we can simplify construction of these compilers?
This might be a good starting point - Pliron. Although the project is still in its early stages, the author has presented some compelling arguments against MLIR’s Rust bindings through the C API and how a native Rust-based compiler IR framework can be advantageous in this context. By the way, he mentions plans to add a (PoC) Cranelift IR dialect, but I don’t believe he has gotten around to implementing it yet.
bjorn3 (Nov 17 2024 at 15:44):Hmm.. if what you are referring to as MLIR is the subproject in LLVM, I think this may not be relevant to my proposal: I did not intend to use MLIR to replace anything. My idea is to provide a reusable compiler infrastructure (written in Rust) that can be used in many different compilers to save development time (instead of just a low-level IR like LLVM/cranelift IR). And this infrastructure may closely resemble the design of MLIR (or it may have many differences, which is exactly what I hope to discuss).
My bad. I though you were proposing to use LLVM's MLIR.
Twice (Nov 18 2024 at 02:34):This might be a good starting point - Pliron.
Wow, I've never heard of that before. Thank you for bringing it to my attention!
I read the author's excellent introduction and comparison, which explains many things. I will continue to explore this project : )
fitzgen (he/him) (Dec 04 2024 at 17:50):@Twice this isn't a fully formed thought but you might also want to look into the nanopass framework and related papers for inspiration of a macro or something for Rust
https://nanopass.org/documentation.html
seems like the kind of thing you might like
Last updated: Dec 23 2024 at 13:07 UTC