+1.
In my experience, working on some parts of LLVM was far more chaotic than anything I’ve seen from MLIR.
In-tree examples:
- LLD has deleted its back-ends one day because some people in a bar agreed it was the right thing to do. For a while we had a long stream of random commits, fixups and typos for LLD more than anything else in LLVM.
- LLDB buildbots are hard to come by and the sub-community pretty much worked completely in separate because testing it is really hard.
- We once decided to completely replace the AArch64 back-end with Apple’s ARM64 version.
- We also decided to have two pass managers for more than a decade.
- We created FastISel that isn’t globally used. We created GlobalIsel to replace that, and neither are widely used. We keep wanting to replace SelectionDAG, but that’s not happening soon.
- Compiler-RT/libcxxabi/libunwind was split, joined and then split again. We have multiple ways to build those things.
- Sanitizers’ history is fraught with instability, fast development, code dumps and unstable testing.
I could go on… I don’t think MLIR stands apart from those examples, and in some cases, is much more conservative.
Were all those examples mistakes? I don’t think so. Creating an incubator for most of of those things would have made it worse IMHO.
Sure, MLIR is more chaotic than a lot of LLVM stuff, but there’s a lot of LLVM stuff that hasn’t changed much since, so I don’t think that’s a fair comparison.