torch-mlir/frontends/pytorch/test/ivalue_import
Sean Silva c837dbb077 Properly import the entire torch::jit::CompilationUnit
This primarily unlocks proper handling of free functions (that is,
functions that are not methods of any torch.nn.Module).

Recommended review order:
- `ivalue_importer.cpp` + `ivalue_import/functions*.py`
- `GlobalizeObjectGraph.cpp` + test case
- misc other stuff

The `torch::jit::CompilationUnit` is basically a backing store or
"context" holding all the possible functions in the program. The
previous code was not explicitly accessing this data structure, since it
just imported the `torch::jit::Function`'s that it saw attached to
methods.

Subtly, any time a TorchScript module called into a free function, the
free function gets incorporated into the torch::jit::CompilationUnit,
but doesn't show up anywhere when dumping the module, except in the
curious pattern:

```
%5 : Function = prim::Constant[name="adaptive_avg_pool2d"]()
%6 : Tensor = prim::CallFunction(%5, %input.1, %4)
```

That is, calls are indirect calls, and are accessed via `prim::Constant`
materializing a function object. Even stranger, the `name` attribute here
doesn't really even tell the full story -- it doesn't correspond to
anything. It turns out that the c10::FunctionType itself actually holds
a pointer to the `torch::jit::Function` in the compilation unit
directly (so there is actually no indirection in prim::CallMethod,
because any two values of the same FunctionType call the same
function!). E.g. when converting the IR to bytecode, the "name" is
ignored [code link](1d6bd15790/torch/csrc/jit/runtime/interpreter.cpp (L937)).
We do import `prim::CallFunction` as a `std.call_indirect` though
because it's more braindead to do it that way (it gets canonicalized to
a direct call easily).
2021-03-01 12:08:01 -08:00
..
annotations Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
README.md Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
functions-that-call-methods.py Properly import the entire torch::jit::CompilationUnit 2021-03-01 12:08:01 -08:00
functions.py Properly import the entire torch::jit::CompilationUnit 2021-03-01 12:08:01 -08:00
list.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
methods-locations.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
methods.py Properly import the entire torch::jit::CompilationUnit 2021-03-01 12:08:01 -08:00
object-identity-error-submodule.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
object-identity-error.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
object-identity-torch-bug.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
object-identity.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
prim.py Properly import the entire torch::jit::CompilationUnit 2021-03-01 12:08:01 -08:00
primitives.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
submodules-select.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
submodules.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
tensors.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00
tuple.py Rename tests to match the code they test 2021-02-25 13:31:33 -08:00

README.md

ivalue_import

Most of the tests in this directory test importing of TorchScript torch::jit::Module's.

Modules are just one of many types of c10::IValue's and recursively contain c10::IValue's. Thus, the work of importing TorchScript modules is mainly about importing the wide variety of possible c10::IValue's, hence the name of this directory and the corresponding code in ivalue_importer.cpp that it exercises.