mirror of https://github.com/llvm/torch-mlir
510f226df2
* Two op interfaces, one for querying instance metadata and one for getting static data needed to construct an op from a generic form. * For torch.generic_kernel ops, metadata is splatted in during capture from Torch (it comes from the op registry, which will work for either device capture or graph import). * Moved the 'add' out of the generated set so I can experiment on it. It implements the TorchBuildableKernelOpInterface interface which provides its metadata. * The ATenRecognizeKernelsPass pass generically lowers from a torch.generic_kernel to recognized ops that implement the TorchBuildableKernelOpInterface, handling the various types of transformations that we allow at this stage. |
||
|---|---|---|
| .. | ||
| 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.