After 3 months we had an IR, lowering to it, lowering out of it, and an optimizer. That IR is suitable for a broad range of use cases for us - basically anytime

After 3 months we had an IR, lowering to it, lowering out of it, and an optimizer. That IR is suitable for a broad range of use cases for us - basically anytime we want to JIT something and are willing to pay for compiler optimizations. In the other two IR design efforts I’ve seen recently, it’s true that after 3 months you have less of the lowering and optimizations. But maybe for one of them it was because the person doing all the work was an intern who hadn’t ever designed an IR before. You’re assuming that: - 3 months is an outlier. It’s not. - 3 months is more than it would take to glue your infrastructure to MLIR. Most likely there is a time cost to adopting it. - that just because someone uses MLIR then they can somehow leverage - at no cost - the MLIR optimizations that someone else did. But MLIR is just scaffold so it’s not obvious that optimizations implemented by one MLIR user would be able to properly handle the semantics of code generated by a different MLIR user. I think this assumption reminds me of how folks 20 years ago thought that if only everyone used XML then we would be able to parse each other’s data. I don’t buy that having MLIR makes it easier to interface different compilers. I’m used to writing lowerings from one IR to another. It’s not that bad and the hardest part is the different semantics; MLIR encourages its various users to invent their own instructions and semantics so I don’t see how to makes this any easier. I think that it’s unfortunate that llvm has as many users as it does. It’s a good C compiler but whenever I see folks doing a straight lowering from something dynamic, I just want to cry. I think that the llvm community is doing a lot of up and coming compiler writers a disservice by getting them to use llvm in cases where they really should have written their own. It’s a big problem in this community.