Slightly off topic (I suspect), but did the cranelift
team ever consider an MLIR
-like architecture for the compiler middle end?
I did a little experiment in the last 2 months where I tried to prototype an MLIR-like thing in Rust (plus go a bit beyond, by writing an abstract interpreter that can be re-configured as required for different analyses/optimizations -- on user-defined lattices): https://github.com/femtomc/abstraps today I started thinking about supporting codegen through cranelift
as part of (one possible) lowering process.
One thing which seems really nice about the dialect/intrinsic extension ideas is that you can (mostly) freely extend the IR framework without worrying about breaking core intrinsics, etc.
I've also found the trait/interface mechanisms in MLIR to be particularly helpful to structure thinking about pass design.
While MLIR is flexible, I think it does come at the cost of compile performance.
bjorn3 said:
While MLIR is flexible, I think it does come at the cost of compile performance.
Yes, agreed. You mean — the concepts must be implemented using dynamic dispatch (dynamism) (?) (I assume) it would be interesting to understand how bad this gets.
@McCoy I think the dynamism would be the main concern w.r.t. compiler performance -- we generate our instruction selector code based on a set of rules that lower the (statically known) set of IR nodes -- but I think a layered approach could be developed here, if there are interesting applications for it
in particular I'm imagining a single "user-defined op" IR node at the CLIF level that can be filled in with whatever behavior, as long as it is lowered before it reaches isel
This is basically what I did in my little experiment (wrt "user-defined op")
I am worried about dynamism costs when applying passes. I'm not really sure how MLIR gets around this in C++. E.g. each time you apply a past, you will likely need to do the equivalent of "cast this trait obj to X to provide access to an interface required by this pass".
I wonder how this is avoided in C++... or perhaps it is not avoided, and it's just the concrete cost of using these extensibility ideas
Last updated: Dec 23 2024 at 12:05 UTC