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. |
||
|---|---|---|
| .. | ||
| Backend/Iree | ||
| CAPI | ||
| Conversion | ||
| Dialect | ||
| Python | ||
| RefBackend | ||
| npcomp-run-mlir | ||
| CMakeLists.txt | ||
| lit.cfg.py | ||
| lit.site.cfg.py.in | ||