mirror of https://github.com/llvm/torch-mlir
fef1733e12
As described in the code comment: ``` When we import TorchScript IR, we import their entire "compilation unit", which can contain numerous functions unrelated to the current program, which breaks torch-globalization-pipeline; for example, there can be random functions referencing types that haven't been imported as part of the root `torch.nn.Module` we imported. Those will be unreferenced private functions which symbol-dce will clean up nicely. ``` This situation is really easy to hit in jupyter notebooks, where the same cell is evaluated multiple times. That results in the same class name (at the Python level, e.g. class `Foo` in the top-level main module). Internally to PyTorch, it handles this situation by mangling in a unique number to the names of ClassType's and such. When we import the new ClassType's, we see not just the new torch::jit::Function's in the CompilationUnit, but, also all the old ones, which reference ClassType's that are not reachable from the `torch.nn.Module` that we imported. Note: there is no way to avoid importing the whole CompilationUnit (including these old remnants) without doing a fairly complicated call graph reachability analysis of which functions are reachable from the methods of the ClassType's we imported. It turns out that once we are inside MLIR, we model visibility correctly so that `symbol-dce` "Just Works" for this use case. That is to say, this is not a quick hack, but rather seems like a totally palatable long-term solution. |
||
|---|---|---|
| .. | ||
| ATen | ||
| Basicpy | ||
| Numpy | ||
| Refback | ||
| Refbackrt | ||
| TCF | ||
| TCP | ||
| Torch | ||
| CMakeLists.txt | ||