mirror of https://github.com/llvm/torch-mlir
e749074bae
These allow users to annotate a known "type bound" on the argument, which can seed shape/dtype inference. We don't rewrite the function types as part of the import process (it will happen in a yet-to-be-written pass) because: 1. We would need to interprocedurally rewrite all calls to keep the IR consistent. Currently, we have a place after GlobalizeObjectGraph but before we convert to tensors where this is convenient to do. Ideally, we would do this on the object graph representation. 1. We don't necessarily know that adjusting the function type is a legal calling convention change. The pass will have blessed knowledge (by the pass pipeline author) that adjusting the argument type based on the type bound is safe (which it frequently is). 2. Note that in principle, a type bound could be a fairly general thing (such as maximum sizes of dimensions, unions of multiple concrete types, etc.). The pass will in principle have logic to interpret the type bounds and to determine a suitable "best" (and legal) argument type. |
||
|---|---|---|
| .. | ||
| pytorch | ||
| 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.