mirror of https://github.com/llvm/torch-mlir
de38caa547
* Make code that depends on the legacy "type dispatch" mechanism optional. * This code is fairly tied to a specific ~1.3 version and uses a legacy dispatch mechanism. * Moving it and making it optional allows the project to build with PyTorch 1.6 and makes it possible for us to start building out a more modern interface mechanism in parallel. * Some of the moved code will be brought back into the more modern path, but isolating it now lets this be done incrementally. * Tests are left failing since the entire frontend is optional and the next step involves reworking the interface mechanism to get them to passing in both regimes. * Fix a few bogons to get things building * Add Dockerfile with pytorch Also, I configure with: -DCMAKE_PREFIX_PATH="/opt/pytorch/pytorch" (which is where pytorch is installed in this container) * Make a dep conditional. Co-authored-by: stephenneuendorffer <stephen.neuendorffer@xilinx.com> |
||
|---|---|---|
| .. | ||
| pytorch | ||
| CMakeLists.txt | ||
| README.md | ||
| __init__.py | ||
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.