RFC: Graduate CIRCT to monorepo?

[mikeurbach]

This is a fascinating and important discussion, but I would like to pop back up to the specific topic of CIRCT and one thought I’ve been mulling over.

@River707

@clattner

Yes, I think this is a good idea. Instead of graduating the entire repo, we can graduate the stable parts of it, and leave the more experimental pieces (e.g. FSM) in the CIRCT repo, or potentially just delete them if they aren’t used.

+1 here. It would be nice to have a clear separation between what is expected for the community to maintain, and what is experimental/not of sufficient quality/stability/coverage/etc.

@stellaraccident

Personally, I think that at least some portion of CIRCT, using MLIR canonically as a frontend for an important domain would actually help us get to more of a “just right” place with respect to cost/benefit.

@stellaraccident

With all of that said, in this one case, I still think that at least some of CIRCT’s dialects rise to the level of being in the monorepo and would be a net gain to both the project and the domain: no matter what the development model, limiting diamond dependency skew for interop components (which is what at least some of CIRCT is) is a worthy thing to look at in its own right.

From these comments’ sentiment, it sounds to me like there is tentative support from the MLIR community to at least have part of CIRCT upstream. This is maybe not the outcome CIRCT had in mind for this RFC, or as an incubator project in general, but what about this…

Rather than upstreaming “the CIRCT project” into the LLVM monorepo as a top-level sub-project (like Flang), maybe the “production quality” dialects and transformations could graduate to upstream MLIR. This would definitely take into account (and potentially help inform) any restructuring of MLIR itself ([RFC] Restructuring of the MLIR repo).

MLIR already has a reasonable process for adding new upstream dialects. Maybe the solution here is to go through that process for the parts of CIRCT we want upstream.

It seems like that would still achieve the goals from the original post and focus additional MLIR maintenance burden on the core CIRCT components. From LLVM’s perspective, this should add similar maintenance burden as other new MLIR dialects.

I am just speaking for myself here, so I’m curious what the other CIRCT community members think.

One counterpoint is it would be more annoying to contribute to both “production” CIRCT components and “experimental” CIRCT components, but again, I don’t think that is the end of the world. I’ve had to do this style of development while evolving the MLIR Python bindings at the same time as I used them in CIRCT, and it is just another process to learn IMHO.