We do take a c++ dependency on torch-mlir but not a direct python dependency, since the torch-mlir python1 stuff brings with it a transitive PyTorch c++ dependency that we don’t want.
We’ll duplicate in the short term and just be careful to propagate changes (which are fairly infrequent). Once the deps and structure settles, we’ll probably just copy these reusable parts into IREE (but not as part of its top level public API) as part of the build system – eliminating the source level duplication. But jumping straight to that being in lock step right now would make our development process harder.
It’s just like three files. I think we can manage that.
Would it be possible to make an announcement here (or somewhere appropriate) if any changes to the importer are made? Just so downstream users know to propagate the changes.
Is moving the FX importer (and corresponding files) the final step in enabling TorchDynamo based export to Torch dialect? And I’m guessing we’ll also have some examples that exercise this e2e flow in torch-mlir. Let us know if we can be of any help moving this along. We’re quite excited to try the new frontend out on some of our models, especially as it would unlock a critical initiative that depends on this work
Yes but I’ve been putting it off because I’m time slicing a lot of priorities and wanted to take some extra time to at least have some in tree tests of it vs a dump and run. That kind of thing isn’t hard but does take a bit of time
Hoping some time frees up as the holidays approach.
We’ve almost got our entire inventory switched to the new path, and the dynamic shape support and some of the other things that we can easily do now have unlocked significant latency and compiler performance optimizations. A lot of that stuff is iree specific but we were hard blocked without cleaning up this layer. Hopefully it helps others too.
Ok, with the above landed, I think we can call this topic closed. Thanks for the feedback and encouragement everyone. There is still more house-cleaning to do, but that is more in the normal vein of the work.
My group has no immediate plans to work on the backend part of the long term roadmap, but I’m open to other interested parties pushing there if there is value.
My group will be taking an interest in test suite conformance (last section of the roadmap) next year. We will likely be pursuing a path that lets us leverage a combination of various ONNX test suites (which now lowers to torch-mlir) and torch-bench.
We should probably just note these items into a revised roadmap.md and delete the current long_term_roadmap.md.
