Hi folks -
I would like to propose that we retire mlir-npcomp as an independent project and rename it within the
llvm organization to
torch-mlir as a first step to finding it a home in the PyTorch ecosystem, which reflects what the project has actually consolidated into (I have access to the rename button in GitHub and am sending this up for feedback before taking that action).
Let me know if there are objections to doing the rename. Some additional information is below.
@_sean_silva is planning an MLIR ODM at some point soon to discuss what, in our view, has been a successful incubation of the project – which is interesting since it ended up consolidating in a direction that was not foreseen at the outset and likely will ultimately result in it finding a home outside of the LLVM Foundation/monorepo. We had foreseen such outcomes when founding the incubator, and we think it is an interesting case study to replay the course that this project took for the community.
To summarize and forecast that future ODM a bit, the project has been narrowly focusing for some time on creating:
torchdialect which can model TorchScript IR and be an import target for newer TorchFX and lazy-tensor work.
- Fairly complete importer for TorchScript.
- Initial importer for TorchFX.
- Reference execution (currently with some in-tree shims but transitioning to use of the MLIR ExecutionEngine).
- Conversions from
torchto upstream compute dialects (currently just
- Test suite of whole models.
- Focus on providing a good PyTorch modeling and import layer while remaining relatively backend agnostic.
The original umbrella goal of working on Python numeric compilation generally has been set aside, and to the extent that it is still being done has been forked and is being developed elsewhere (i.e. see the
iree_pydm dialect in the
At this point, it makes sense to name the repository based on what it has actually evolved into. This work has started by extracting the newly focused core into
external/torch-mlir with a subsequent step (in the next week or so), essentially replacing the top-level with this sub-directory, updating README, etc (once a couple more things are cleaned up and moved such as the integration tests and reference runner). Renaming in this way will signal to the various communities what the project is trying to be vs the current name, which causes ambiguity.
As mentioned, we feel that this has been a successful incubation and thank the LLVM community for hosting. Having it be associated with the project has brought about connections, upstreaming opportunities and collaborations that helped turn it into what it is and would have been much more disconnected otherwise. Some of the items that were upstreamed out of npcomp:
- Substantial parts of the MLIR Python bindings were direct ports of npcomp’s v0 bindings and the original Python compiler was a nice driving use case for the API in general (and was the first non trivial user of them).
- The way that MLIR Python is packaged and deployed was directly developed in npcomp and upstreamed. It was really important to have an actual product that was trying to produce user-focused artifacts to drive such a thing.
- Fixing longstanding dynamic linkage bugs (which largely impacted out of tree projects) was motivated by the need to deploy npcomp. Without that, I may not have converged on and landed the ultimate fixes.
- Extending the MLIR Python bindings by out of tree projects was piloted in npcomp/upstreamed and is in use by CIRCT, IREE, MHLO, etc.
- In npcomp, we converged on a pretty nice way to share and integrate dialect projects among external projects, making the C-API and Python APIs interop and compose nicely, especially from the build system, which was previously hard to see in a pure-upstream/monorepo world (this is now the defacto way that we integrate npcomp, MHLO, frontend iree-dialects, iree-compiler-api, and circt).
Looking forward to presenting more as the project further consolidates.
Stella, on behalf of npcomp contributors