McCoy (Jan 02 2022 at 00:18): McCoy (Jan 02 2022 at 00:18):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.
bjorn3 (Jan 02 2022 at 11:20):While MLIR is flexible, I think it does come at the cost of compile performance.
McCoy (Jan 02 2022 at 18:18):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.
Chris Fallin (Jan 03 2022 at 17:37):@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
Chris Fallin (Jan 03 2022 at 17:37):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
McCoy (Jan 03 2022 at 17:50):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: Oct 23 2024 at 20:03 UTC