[RFC][Incubation] Request for incubating TCP dialect for MLIR

[bondhugula]

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.

[mehdi_amini]

@clattner

I am extremely concerned with the amount of stuff that is put into the MLIR repository (and thus the LLVM monorepo) that is not up the the standards of the rest of the LLVM project.

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.

@clattner

but when it joined the LLVM project it didn’t fully adopt the LLVM contribution model

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).

[ftynse]

@clattner

This is a growing concern of mine, perhaps we can have a discussion/bof/etc about this at the LLVM Dev Mtg this fall.

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.

@mehdi_amini

(we may be getting a bit off-topic for the incubator request though).

I don’t think there is a way to split out some of the comments from this thread, is there?

[rengolin]

@mehdi_amini

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.

+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.

[aartbik]

@mehdi_amini

@clattner

I am extremely concerned with the amount of stuff that is put into the MLIR repository (and thus the LLVM monorepo) that is not up the the standards of the rest of the LLVM project.

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.

+1 on Mehdi’s response. I would like to hear as well, constructively of course, what amount of stuff Chris is alluding to here.