llvm
/
torch-mlir
mirror of https://github.com/llvm/torch-mlir
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
torch-mlir/frontends
History
Sean Silva 39d50ccf0d Add end-to-end testing framework for TorchScript. 
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.
 		2021-04-20 12:00:35 -07:00
..
pytorch Add end-to-end testing framework for TorchScript. 2021-04-20 12:00:35 -07:00
README.md Create frontends/pytorch directory. (#31) 2020-08-18 09:43:20 -07:00
__init__.py Add pytorch interface to ATen Dialect (#30) 2020-08-21 11:22:47 -07:00

README.md

NPComp - Frontends

NPComp maintains in-tree frontends for various popular numeric-python based frameworks. In general these are:

  • Considered optional components
  • Target dialects maintained at the top-level of the project
  • Maintained in isolation so as to facilitate moving them out to dedicated projects at an appropriate point of the lifecycle (i.e. if NPComp is successful as a general purpose target for such frameworks, then it may make sense to contribute/build each frontend to their respective up-stream project).

Frontends try to stylistically fit into the outer project except for when it is more clear/advantageous to align them with the conventions of the source project. This is approached on a case by case basis as needed. Deviations should be documented in a local style guide for the frontend.