[RFC] Proposal for a high-level ML dialect in MLIR

[mehdi_amini]

@clattner

I also agree with the second point. MLIR already has a lot of “advanced research quality” code in the main MLIR tree, and it is difficult to know the capabilities and limitations of that code. Much of this is ML focused (e.g. linalg) but other is more generic (affine etc). Splitting these out from MLIR core seems like it would help differentiate the pretty-battle-tested stuff like SCF from the more researchy and evolving pieces.

I believe we need better separation (remember [RFC] Restructuring of the MLIR repo ? I sent patches but never finished it to the point of landing the changes…) but I also strongly believe that:

@ftynse

IMO, having an end-to-end ML compilation pipeline somewhere within LLVM and the right communication around it is important in the long term. I speak about MLIR quite a bit and, while I do insist on it being an infrastructure, the most common questions I get are “how do I try it?” and “is it faster than X on Y platform?”
[…]
We need a tested and supported “happy path”. Whether it exists because we add more dialects to the MLIR main directory or because we create a separate “mlcompiler” is secondary.

For example: I want us to get to have a end-to-end TOSA compiler in-tree for CPU/GPU, with integration tests, etc.
This does not have to be the only way someone compiles TOSA (or other), but I don’t see why the fact that some people may want to do it differently or don’t want to work upstream should prevent an interested set of people to collaborate in-tree.
This is also my motivation for the repo restructuring: protect the core of the project while preserving the ability to collaborate on building one or multiple end-to-end story: modularity of MLIR should also allow to do this and reuse pieces / dialects / components in various end-to-end scheme.

The problem of Coordinate LLVM commits for different project is a feature to me: people are encouraged to upstream their code to LLVM (and MLIR) because they pay a somehow high price of updating their code out-of-tree.

@stellaraccident

Just last week, I deleted the quant ops that had ended up only being used by TFLite, and that inadvertently cost one week of integrate heroics to untangle in Google’s open source products.

And the removal from OpaqueAttr from MLIR Core (builtin dialect) is even more impactful than that: we’re still working on the fixes to adjust to that right now! That’s telling of MLIR Core “stability” somehow as well (and there are a few breaking thing that may happen in Core still).