Last year, we had great success in bringing tvm ffi into its own independent module, as of now, tvm-ffi serves as a standalone ABI that powers many solutions in ML systems and compilers.
The trend of agentic era brings more needs for modular foundations, TIRx helps us to bring in another modular component that could help serve as a minimal foundation for enabling connection to stable compiler toolchain, driect codegen to cuda layer or host codegen a tvm-ffi interface. It would also give use low-level access to hardware for major kernel needs. This foundation layer would include the predictable, stable components while continue to enable smart solutions to be built on top by agent and developers.
In this post, we would like to propose moving tirx and minimum set of low-level components into its own separate repo, this will allow the particular module to:
Retain minimum dependency and self-contained
Its own release schedule, which likely should favor stability, minimalism and reuse across projects
Potentially benefit more projects by developers and agent.
Hopefully that would marks a milestone that helps us to modularize the project further.
Supportive towards this direction. Having a relatively independent, self-contained and minimal foundation in a separate repo makes it easier for people who need just that foundation since they won’t have to install the giant full TVM package. People can also use their agent to build whatever they want on top of the foundation.
I agree! This direction makes a lot of sense, especially in the agentic era where having modular and composable foundations becomes increasingly important.
Once TIRx matures into a stable, minimal infrastructure layer, it can provide a very solid foundation for higher-level systems, while also making it much easier for repos to build on top of it independently.
I support splitting the TIRx foundation into a separate repository. Keeping it self-contained with minimal dependencies and an independent release schedule should make it easier for downstream projects to adopt and build on.
It would be great to have it as a separate repository!
In my experience, TIRx offers exceptional (unmatched so far by any other) expressivity when it comes to loop representation and transformation. In real-world workloads, this plasticity provides a distinct advantage over standard MLIR dialects, which can sometimes feel rigid (think of affine maps or scf loops) for complex schedule manipulations.
It is also a great opportunity to add some kind of reflection for TIRx:
This would enable easy inspection of the dialect and integration with external tooling.
It would be possible to auto-generate IR catalogs, documentation, and tooling bindings seamlessly. For example, it would make it super easy for third parties to generate MLIR TableGen definitions and connect TIRx directly into the broader MLIR ecosystem.