[pizlonator]

Nice things first: I think that MLIR is a great solution to the problem of reusable IR scaffold (infrastructure, storage, serialization). If you believe that this is a problem and you don’t do anything that MLIR can’t express at all or well (OSR at scale, non-SSA forms), and you don’t have a plan to change the scaffold to fit your use case, then I think that MLIR is a pretty nifty achievement.

I just don’t buy the premise because IR scaffolds are something I’m used to building quickly.

[Joky]

You are making good point, but I think you're missing some aspects and the title hints about it: we are also trying to address today's heterogeneity. By having a flexible infrastructure and (hopefully) an ecosystem with which the interaction cost is lowered, you can re-assemble more easily custom compilers for specific use-cases.

This does not make MLIR the best infrastructure for building an industrial embedded Javascript compiler for instance (just like you wrote B3 to move away from LLVM), but I am not convinced that between these two, MLIR is the niche ;-) Time will tell!

[pizlonator]

But MLIR is so limited in what it can do - a specific style of SSA, a specific module and procedure structure, etc. Even the features that make it general (regions) represent a specific choice of how to do it.

Great IRs represent an ideal fit between data structures, data flow style, control style, and the domain. Llvm is successful because it fits C so darn well - it’s like SSAified C. I’m not sure what MLIR is an ideal fit for. It just feels like another Phoenix.