llvm
/
torch-mlir
mirror of https://github.com/llvm/torch-mlir
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
torch-mlir/test/python/fx_importer/v2.3/lit.local.cfg

10 lines
187 B
INI
Raw Normal View History

[fx] Support mutation in ExportedProgram. (#2916) As of https://github.com/pytorch/pytorch/pull/118969, `ExportedProgram` has the long awaited fixes to correctly categorize various things relating to parameters, buffers, mutated inputs and constants. With this additional modeling, we are finally able to implement (safely/soundly) the mutable semantics that were attempted on the TorchScript path. The difference is that on that path, we had to conservatively treat everything as mutable and run some dodgy heuristics (which have been the cause of many bugs relating to "MaximizeValueSemantics") to try to get back to an immutable state. The new model supports mutability at the graph edges, allowing both user inputs and buffers to be mutated (there is some more support than that, but that is all I fully tracked through to implementation). Therefore, when we receive programs like this, we now can selectively enable mutation at the edges. This happens to be the mutability model that IREE supports, which I expect to be a primary beneficiary. However, there is nothing stopping anyone else from handling the `!torch.tensor` types and the existing copy/overwrite ops that will be selectively added. Since this relies on API changes that will not release until 2.3, I'm being a bit cautious about not refactoring existing facilities.
2024-02-17 01:46:30 +08:00
config.unsupported = True
try:
import torch
[fx] Implement auto_functionalized higher order op. (#3063) * Also adds the basic scaffolding for handling more of these, which will be needed for cond, while, etc. * Refactors some of the support in the generic OpOverload emitter so it can be shared with these other special forms. This has been on my list for a while, but it just so happens that as part of upgrading to PyTorch 2.3 and a pure upstream flow in Turbine, we were using a feature that required integration with auto_functionalized. This is perhaps the "weirdest" of the higher-order ops and a poor place to start, but needs must. We have testing for this in Turbine. Full support in Turbine has an entire custom ops facility. I've reduced this down to a unit test in torch-mlir.
2024-03-27 08:06:05 +08:00
if torch.__version__ >= "2.3.0":
[fx] Support mutation in ExportedProgram. (#2916) As of https://github.com/pytorch/pytorch/pull/118969, `ExportedProgram` has the long awaited fixes to correctly categorize various things relating to parameters, buffers, mutated inputs and constants. With this additional modeling, we are finally able to implement (safely/soundly) the mutable semantics that were attempted on the TorchScript path. The difference is that on that path, we had to conservatively treat everything as mutable and run some dodgy heuristics (which have been the cause of many bugs relating to "MaximizeValueSemantics") to try to get back to an immutable state. The new model supports mutability at the graph edges, allowing both user inputs and buffers to be mutated (there is some more support than that, but that is all I fully tracked through to implementation). Therefore, when we receive programs like this, we now can selectively enable mutation at the edges. This happens to be the mutability model that IREE supports, which I expect to be a primary beneficiary. However, there is nothing stopping anyone else from handling the `!torch.tensor` types and the existing copy/overwrite ops that will be selectively added. Since this relies on API changes that will not release until 2.3, I'm being a bit cautious about not refactoring existing facilities.
2024-02-17 01:46:30 +08:00
print("Enabling Torch v2.3+ tests")
[NFC reformat] Run pre-commit on all files and format misc. This is part 1 of ~3, formatting all miscellaneous text files and CPP files matched by a first run of pre-commit. These tend to be low change-traffic and are likely not disruptive. Subsequent patches will format Python files and remaining CPP files.
2024-04-28 05:08:09 +08:00
config.unsupported = False
[fx] Support mutation in ExportedProgram. (#2916) As of https://github.com/pytorch/pytorch/pull/118969, `ExportedProgram` has the long awaited fixes to correctly categorize various things relating to parameters, buffers, mutated inputs and constants. With this additional modeling, we are finally able to implement (safely/soundly) the mutable semantics that were attempted on the TorchScript path. The difference is that on that path, we had to conservatively treat everything as mutable and run some dodgy heuristics (which have been the cause of many bugs relating to "MaximizeValueSemantics") to try to get back to an immutable state. The new model supports mutability at the graph edges, allowing both user inputs and buffers to be mutated (there is some more support than that, but that is all I fully tracked through to implementation). Therefore, when we receive programs like this, we now can selectively enable mutation at the edges. This happens to be the mutability model that IREE supports, which I expect to be a primary beneficiary. However, there is nothing stopping anyone else from handling the `!torch.tensor` types and the existing copy/overwrite ops that will be selectively added. Since this relies on API changes that will not release until 2.3, I'm being a bit cautious about not refactoring existing facilities.
2024-02-17 01:46:30 +08:00
except ModuleNotFoundError:
...