[RFC] MLIR Project Charter and Restructuring

In recent years we have discussed many changes to the MLIR infrastructure, dialects, conversions, representations, transforms and their future. There is a sense of stagnation on progressing those critical issues from fragmentation created by lack of clarity on what is the purpose of MLIR in general.

Like LLVM, there are a number of external (upstream and downstream) users of various levels of the infrastructure, from just the core logic to all dialects and transforms. Unlike LLVM (few front-ends, single IR, default pipeline, specific targets), there isn’t a well defined core semantics for the whole compiler, which makes it really hard to even define what MLIR is to begin with.

Multiple (partial) solutions have been floated and many of them incompatible with each other. For example, dialect independence (being able to import dialects from other projects) really needs substantial changes to the core infrastructure of what a dialect is and how to connect it to the rest of the ecosystem. Another example is the expected semantics of some dialects and disagreement leading to new dialects (example is the Linalg/TOSA/TCP Venn diagram), some of which do not “make the cut” upstream for often unclear reasons. Finally, there’s an idea of “purity of design” that is subjective and not actionable, while there’s the pressure to “get work done” that runs against that in the opposite corner. Neither are good positions to be in, but we have yet to find where we stand in that spectrum.

We need to agree to a common charter, at both high level (what MLIR is and how it fulfils its purpose with lowest global cost) and low-level (dialect semantics and conversions, what does canonicalization means, type systems, etc). The old code ownership model does not work here because of the number of voices and the disconnected nature of the MLIR infrastructure, more as a “tool bag” than a tool itself.

Leave a Comment