Replace tm_tensor with torch-mlir proper #14917
Conversation
stellaraccident
requested review from
MaheshRavishankar,
benvanik,
ScottTodd and
pzread
as code owners
…ned and optional. While working on iree-org/iree#14917, I noticed that it is somewhat hard to take a dependency on torch-mlir such that one only builds deps for the target(s) of interest (in this case Linalg). I noticed that some ifdef'ey optionality was added for stablehlo, but this was not mirrored for the others. Further, it does the switching very deep in the dependency graph vs having top-level directories and defines gating entire features. In addition, I noticed that a lot of things in the Linalg path were broken down to a fine level of detail but were not actually shared/shareable outside of that target. I opted to clump these together into TorchToLinalg. It is easy enough to "promote" them to common with this new organization if the need arises. General approach: * Isolate each conversion target in one of TorchToLinalg, TorchToStablehlo, TorchToTosa. * Gate each by top-level CMake flags and defines. * Common conversions go in a Common/ directory (currently Arith and SCF). * Pull target specific conversions out of TorchConversion/Transforms and put in their top-level directory. * General maintenance on the build graph and registration stuff that had bitrotted and was blocking progress. The main functional change for people taking a source dep is that `#include "torch-mlir/Conversion/Passes.h"` no longer is a one stop shop: For optional conversions, you have to include the dedicated `Passes.h` of each and take a library dep. See `InitAll.cpp` which does it right (and *is* a one stop shop still).
|
Does torch become a plugin proper now? Having this dep be optional is important for usage where not all packages are available (or desirable). |
|
Yes, it is entirely self contained as compiler/plugins/input/Torch This should be an improvement for such cases over the previous state where it was optional but still threaded through the main codebase. |
Per discussion on iree-discuss, this patch removes the original tm_tensor source snapshots and special casing from the codebase, instead pulling in the parts of torch-mlir that provide a full solution, starting from the torch dialect down. This reuses the existing `IREE_INPUT_TORCH` CMake define but routes it to a compiler plugin at `compiler/plugins/input/Torch` where all build plumbing to integrate and local pipelines exist. I have kept the original tm_tensor input type for the moment since downstreams are using that, but we will want to eventually replace that with a dedicated `torch` input type which works directly from the `torch` dialect. This patch should be NFC to all current users, however it allows programmatic and API access to the full Torch dialects and conversion pipelines, which is essential for broader scale integration. We add `third_party/torch-mlir` as a submodule at torch-mlir's current HEAD. During LLVM integrates, if there are ever API breaks that affect this, we may need to push patches to torch-mlir to address. This can be done on a torch-mlir branch as needed (or committed at head). I have been tracking changes for a couple of months and have not had a need to do this yet, which indicates that this is relatively stable. Committing with an XFAIL'd lit test, which for some reason was not running previously and now is: iree-org#14916
|
Ah... I just noticed that if someone runs Not sure how we could improve the situation there... maybe write down the git submodule workflows we suggest and keep an eye on downstream projets (e.g. https://github.com/RechieKho/IREE.gd#build-from-source)? |
The instructions at https://github.com/iree-org/iree-template-runtime-cmake/ should also be updated to account for that too:
Output even with that (https://github.com/iree-org/iree-template-runtime-cmake/actions/runs/6656984452/job/18090744983): |
Per discussion on iree-discuss, this patch removes the original tm_tensor source snapshots and special casing from the codebase, instead pulling in the parts of torch-mlir that provide a full solution, starting from the torch dialect down.
This reuses the existing
IREE_INPUT_TORCHCMake define but routes it to a compiler plugin atcompiler/plugins/input/Torchwhere all build plumbing to integrate and local pipelines exist. I have kept the original tm_tensor input type for the moment since downstreams are using that, but we will want to eventually replace that with a dedicatedtorchinput type which works directly from thetorchdialect.This patch should be NFC to all current users, however it allows programmatic and API access to the full Torch dialects and conversion pipelines, which is essential for broader scale integration.
We add
third_party/torch-mliras a submodule at torch-mlir's current HEAD. During LLVM integrates, if there are ever API breaks that affect this, we may need to push patches to torch-mlir to address. This can be done on a torch-mlir branch as needed (or committed at head). I have been tracking changes for a couple of months and have not had a need to do this yet, which indicates that this is relatively stable.Committing with an XFAIL'd lit test, which for some reason was not running previously and now is: #14916