I too strongly support this RFC. Given the dialect’s goals, if everything goes right, I think this should get into the MLIR tree and subsume/replace some of the existing abstractions there.
We should look into details at what you’re aiming at here, my experience has been quite opposite to you here: the code that goes into MLIR seems in general held to a much higher bar than most other areas in LLVM. Just being more recent means also that MLIR is more consistent and managed to keep a somehow uniform coding standard and practices.
It would be great if you can link to the documentation that define the “LLVM contribution model” and precise which part of it MLIR does not adhere to: it isn’t clear to me what you have in mind here.
In my experience MLIR is much more consistent than LLVM with respect to using RFC for changes and pre-commit code review for almost anything. I don’t think any important change hasn’t been discussed on the forum publicly before going in.
Also, we only documented things we wanted to be “more strict” than LLVM: Developer Guide - MLIR ; we don’t have any practice that shouldn’t be covered by the general LLVM documentation otherwise.
(we may be getting a bit off-topic for the incubator request though).
Discussing this face-to-face is a good idea, with the above-mentioned caveat of remaining inclusive towards folks who may not be able to travel for this particular occasion.
I don’t think there is a way to split out some of the comments from this thread, is there?
In my experience, working on some parts of LLVM was far more chaotic than anything I’ve seen from MLIR.
- 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.
+1 on Mehdi’s response. I would like to hear as well, constructively of course, what amount of stuff Chris is alluding to here.