mirror of https://github.com/llvm/torch-mlir
39d50ccf0d
The E2E tests can be run with ``` npcpy frontends/pytorch/e2e_testing/torchscript/main.py ``` This commit adds a couple items supporting that end, including new sugar for annotations (no more raw use of ClassAnnotator!). Recommended review order: 1. `frontends/pytorch/e2e_testing/torchscript/main.py` for the harness + `basic.py` in that directory for examples of tests. 2. Annotation sugar in `frontends/pytorch/python/torch_mlir/torchscript/annotations.py` and unittest in `frontends/pytorch/test/ivalue_import/annotations/sugar.py` 3. Global test registry / sugar in `frontends/pytorch/python/torch_mlir/torchscript/e2e_test/registry.py` 4. `frontends/pytorch/python/torch_mlir/torchscript/e2e_test/framework.py` for the meat of the testing framework (start at `run_tests`), and looking at the backend configs in `frontends/pytorch/python/torch_mlir/torchscript/e2e_test/configs` for examples of backends. This is likely the bulk of review time. 5. Unit tests of the framework logic in `frontends/pytorch/test/torchscript_e2e_test` There's TODO's scattered throughout, but this seems functional enough to start pulling stuff into and kicking the tires. A few missing pieces: 1. Marking test expected pass/fail per backend. 2. Figuring out how best to fit this into dev workflows. 3. IREE TestConfig. Also, forgive this Python newbie... Any advice on Python code structure / library design would be much appreciated. |
||
---|---|---|
.. | ||
annotations | ||
README.md | ||
functions-that-call-methods.py | ||
functions.py | ||
list.py | ||
methods-derefine.py | ||
methods-locations.py | ||
methods.py | ||
object-identity-error-submodule.py | ||
object-identity-error.py | ||
object-identity-torch-bug.py | ||
object-identity.py | ||
prim.py | ||
primitives.py | ||
strings.py | ||
submodules-select.py | ||
submodules.py | ||
tensors.py | ||
tuple.py |
README.md
ivalue_import
Most of the tests in this directory test importing of TorchScript
torch::jit::Module
's.
Modules are just one of many types of c10::IValue's and recursively contain c10::IValue's. Thus, the work of importing TorchScript modules is mainly about importing the wide variety of possible c10::IValue's, hence the name of this directory and the corresponding code in ivalue_importer.cpp that it exercises.