(Early disclaimer: I am an author of the paper and of MLIR, but this is a personal opinion)

I am somehow surprised by the reaction but at the same time I expected as much. We chose to make MLIR open-source early in the design and development, may be half a year after the first line was written, because we value open source and believe that a community can help build significantly better things that serve a broader audience. I find it unreasonable to expect a new infrastructure to have the same amount of frontends/optimizers/backends/utilities/bells-and-whistles as a project that has been around for 17 years and has got contributions from hundreds of developers employed by dozens of companies. 15 years ago, LLVM only had a fraction of what it has today... By making MLIR open from the start, we let everybody add the whistles they need, or collaborate on them with other people who also need them. That is sort of the point of open source community. Personally, I am happy to work with anybody who shares my needs, but I won't do somebody else's job instead of them. In a sense, MLIR does not intend to solve any specific compiler problem, but rather give people tools that help them focus on the problem at hand instead of IR infrastructure, storage, serialization etc.

The alternative would have been to develop it internally for a long time, driven exclusively by the internal needs, and then just throw it over the fence into public. It would have had significantly more "features". I am certain some people would have complained about that process as well.

As for the need of MLIR when LLVM already exists: yes, you could express a lot of things by (ab)using LLVM IR, but sometimes it's worth considering whether you should. Loop optimizations is the canonical example of LLVM IR's limitations [1,2]. Peculiarities of GPU execution model are another [3,4]. People spent years on trying to fit those into LLVM's constraints. Generic passes like DCE, CSE and inlining are (re)implemented on many levels of IRs, which seems more like the time-consuming wheel reinvention than doing an infrastructure that can be reused for those.

TL;DR: if you want a compiler giving faster code for language X today, MLIR is probably not for you, also today; if LLVM already does everything you need, MLIR is probably not for you either. There are plenty of other cases around.

[1] http://polly.llvm.org [2] http://lists.llvm.org/pipermail/llvm-dev/2020-January/137909... [3] http://nhaehnle.blogspot.com/2016/10/compiling-shaders-dynam... [4] http://lists.llvm.org/pipermail/llvm-dev/2019-October/135929...