Right now, it seems to me that a very large majority of the upstream MLIR contributor working on codegen are using these abstraction and this style of codegen (tensor based). It’s not clear to me why you think they should move downstream? I believe that the upstream community should be able to do what they think is right and explore it in tree: the people the most involved with contributing to the project should be able to drive this kind of things.
This is a very valid position, as Stella mentioned we had a discussion at the dev meeting on this topic and I see multiple ways forward. One of them is to resume the implementation of my previous proposal (patches were approved but never landed) [RFC] Restructuring of the MLIR repo and separate in-tree the core infra from the codegen.
Another approach would be to move to incubator projects all the various components that aren’t core.
I believe the community is interested in working on a “Tensor Compiler” in MLIR (and in the MLIR fashion, it should be made of modular and reusable component). This work can exist in tree or out-of-tree. If we believe that the work in-tree should be restricted to core component, and answer the “is it really core/central to MLIR?”, we’d also have to find a place for things like the affine dialect (maybe its own incubator, it’s not specific to tensor compilers…) and others (see the RFC about the restructuring to see what is really “core”).
I have a strong preference to work in-tree, I think our current flat directory structure isn’t enough to scale (hence the RFC from last year). But I’m also open to something more drastic where components get moved out-of-tree. That said I don’t believe a web of repository is maintainable/scalable, and it’s not clear to me how we can get to a point where component like we have now can be reused by many projects (IREE, XLA, and others like @rdicecco) without being in the same place. Also any new project would have to weight the cost of reusing something in another repo or reimplementing something, knowing the issues with LLVM/MLIR APIs instability this creates also a nightmare if you want to reuse Tensor and Affine but they leave in a different repo and they don’t get updated together to the same MLIR upstream version.
With out-of-tree components, if I were to start an MLIR based project, I would want to use a single repo as the source (it could be a single incubator like Torch-MLIR) and get MLIR through there. I would add any dependency on any other dialect or MLIR component then.
I believe MLIR having as many tools out-of-the-box as possible (all being optionals) is what will make it a great platform for research and innovation, at the lowest cost possible.