llvm
/
torch-mlir
mirror of https://github.com/llvm/torch-mlir
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
torch-mlir/build_tools/update_torch_ods.sh

49 lines
1.8 KiB
Bash
Raw Normal View History

[torch-mlir earthmoving (2/N)] Python code movement. This moves the bulk of the Python code (including the Torch interop) from `frontends/pytorch` into `torch-mlir/TorchPlugin`. This also required reconciling a bunch of other Python-related stuff, like the `torch` dialects. As I did this, it was simpler to just remove all the old numpy/basicpy stuff because we were going to delete it anyway and it was faster than debugging an intermediate state that would only last O(days) anyway. torch-mlir has two top-level python packages (built into the `python_packages` directory): - `torch_mlir_dialects`: `torch` dialect Python bindings (does not depend on PyTorch). This also involves building the aggregate CAPI for `torch-mlir`. - `torch_mlir`: bindings to the part of the code that links against PyTorch (or C++ code that transitively does). Additionally, there remain two more Python packages in npcomp (but outside `torch-mlir`): - `npcomp_torch`: Contains the e2e test framework and testing configs that plug into RefBackend and IREE. - `npcomp_core`: Contains the low-level interfaces to RefBackend and IREE that `npcomp_torch` uses, along with its own `MLIR_PYTHON_PACKAGE_PREFIX=npcomp.` aggregation of the core MLIR python bindings. (all other functionality has been stripped out) After all the basicpy/numpy deletions, the `npcomp` C++ code is now very tiny. It basically just contains RefBackend and the `TorchConversion` dialect/passes (e.g. `TorchToLinalg.cpp`). Correspondingly, there are now 4 main testing targets paralleling the Python layering (which is reflective of the deeper underlying dependency structure) - `check-torch-mlir`: checks the `torch-mlir` pure MLIR C++ code. - `check-torch-mlir-plugin`: checks the code in `TorchPlugin` (e.g. TorchScript import) - `check-frontends-pytorch`: Checks the little code we have in `frontends/pytorch` -- mainly things related to the e2e framework itself. - `check-npcomp`: Checks the pure MLIR C++ code inside npcomp. There is a target `check-npcomp-all` that runs all of them. The `torch-mlir/build_standalone.sh` script does a standalone build of `torch-mlir`. The e2e tests (`tools/torchscript_e2e_test.sh`) are working too. The update_torch_ods script now lives in `torch-mlir/build_tools/update_torch_ods.sh` and expects a standalone build. This change also required a fix upstream related to cross-shlib Python dependencies, so we also update llvm-project to 8dca953dd39c0cd8c80decbeb38753f58a4de580 to get https://reviews.llvm.org/D109776 (no other fixes were needed for the integrate, thankfully). This completes most of the large source code changes. Next will be bringing the CI/packaging/examples back to life.
2021-09-11 02:44:38 +08:00
#!/bin/bash
# Updates auto-generated ODS files for the `torch` dialect.
Allow torch-mlir to support PyTorch extensions. (#895) PyTorch allows new operators to be registered dynamically in modules. Torch-mlir already makes it fairly straightforward to add support for new operators, and this commit just extends that support to allow new PyTorch ops to come from a external module. This does *not* allow ops to be dynamically loaded into torch-mlir. Torch-mlir must still be compiled with support built-in. Add a `_torch_mlir_custom_op_example` subpackage to `torch_mlir` which registers an demonstration op. It will not be imported by default when importing torch_mlir. It's strictly for testing and documentation. Adds an end-to-end test for the `torch_mlir_custom_op_example::identity` op. With all these changes, we should now be actively testing PyTorch extension support with all future patches.
2022-06-14 05:51:30 +08:00
#
# Environment variables:
# TORCH_MLIR_EXT_MODULES: comma-separated list of python module names
# which register custom PyTorch operators upon being imported.
# TORCH_MLIR_EXT_PYTHONPATH: colon-separated list of paths necessary
# for importing PyTorch extensions specified in TORCH_MLIR_EXT_MODULES.
# For more information on supporting custom operators, see:
# ${TORCH_MLIR}/python/torch_mlir/_torch_mlir_custom_op_example/README.md
build: improve robustness of cmake and shell scripts (#1018) On my local machine, `unzip` didn't exist (producing a "command not found" error), but CMake ignored the error. Although the build did succeed (because it found a previously-built version of libtorch), it seems better to abort builds on such failures, so this patch checks the return code of all external process invocations. Along similar lines, this patch also updates the shell scripts in `build_tools` to extensively use double-quoting to prevent unintentional word splitting or globbing. Since some of the scripts execute `rm` while using shell variables, this patch also adds the preamble `set -u` to abort execution if an undefined variable is referenced, so that we reduce the chances of executing `rm -rf /` if the path expression happens to refer to an undefined variable.
2022-07-07 05:39:30 +08:00
set -euo pipefail
[torch-mlir earthmoving (2/N)] Python code movement. This moves the bulk of the Python code (including the Torch interop) from `frontends/pytorch` into `torch-mlir/TorchPlugin`. This also required reconciling a bunch of other Python-related stuff, like the `torch` dialects. As I did this, it was simpler to just remove all the old numpy/basicpy stuff because we were going to delete it anyway and it was faster than debugging an intermediate state that would only last O(days) anyway. torch-mlir has two top-level python packages (built into the `python_packages` directory): - `torch_mlir_dialects`: `torch` dialect Python bindings (does not depend on PyTorch). This also involves building the aggregate CAPI for `torch-mlir`. - `torch_mlir`: bindings to the part of the code that links against PyTorch (or C++ code that transitively does). Additionally, there remain two more Python packages in npcomp (but outside `torch-mlir`): - `npcomp_torch`: Contains the e2e test framework and testing configs that plug into RefBackend and IREE. - `npcomp_core`: Contains the low-level interfaces to RefBackend and IREE that `npcomp_torch` uses, along with its own `MLIR_PYTHON_PACKAGE_PREFIX=npcomp.` aggregation of the core MLIR python bindings. (all other functionality has been stripped out) After all the basicpy/numpy deletions, the `npcomp` C++ code is now very tiny. It basically just contains RefBackend and the `TorchConversion` dialect/passes (e.g. `TorchToLinalg.cpp`). Correspondingly, there are now 4 main testing targets paralleling the Python layering (which is reflective of the deeper underlying dependency structure) - `check-torch-mlir`: checks the `torch-mlir` pure MLIR C++ code. - `check-torch-mlir-plugin`: checks the code in `TorchPlugin` (e.g. TorchScript import) - `check-frontends-pytorch`: Checks the little code we have in `frontends/pytorch` -- mainly things related to the e2e framework itself. - `check-npcomp`: Checks the pure MLIR C++ code inside npcomp. There is a target `check-npcomp-all` that runs all of them. The `torch-mlir/build_standalone.sh` script does a standalone build of `torch-mlir`. The e2e tests (`tools/torchscript_e2e_test.sh`) are working too. The update_torch_ods script now lives in `torch-mlir/build_tools/update_torch_ods.sh` and expects a standalone build. This change also required a fix upstream related to cross-shlib Python dependencies, so we also update llvm-project to 8dca953dd39c0cd8c80decbeb38753f58a4de580 to get https://reviews.llvm.org/D109776 (no other fixes were needed for the integrate, thankfully). This completes most of the large source code changes. Next will be bringing the CI/packaging/examples back to life.
2021-09-11 02:44:38 +08:00
build: improve robustness of cmake and shell scripts (#1018) On my local machine, `unzip` didn't exist (producing a "command not found" error), but CMake ignored the error. Although the build did succeed (because it found a previously-built version of libtorch), it seems better to abort builds on such failures, so this patch checks the return code of all external process invocations. Along similar lines, this patch also updates the shell scripts in `build_tools` to extensively use double-quoting to prevent unintentional word splitting or globbing. Since some of the scripts execute `rm` while using shell variables, this patch also adds the preamble `set -u` to abort execution if an undefined variable is referenced, so that we reduce the chances of executing `rm -rf /` if the path expression happens to refer to an undefined variable.
2022-07-07 05:39:30 +08:00
src_dir="$(realpath "$(dirname "$0")"/..)"
[torch-mlir earthmoving (2/N)] Python code movement. This moves the bulk of the Python code (including the Torch interop) from `frontends/pytorch` into `torch-mlir/TorchPlugin`. This also required reconciling a bunch of other Python-related stuff, like the `torch` dialects. As I did this, it was simpler to just remove all the old numpy/basicpy stuff because we were going to delete it anyway and it was faster than debugging an intermediate state that would only last O(days) anyway. torch-mlir has two top-level python packages (built into the `python_packages` directory): - `torch_mlir_dialects`: `torch` dialect Python bindings (does not depend on PyTorch). This also involves building the aggregate CAPI for `torch-mlir`. - `torch_mlir`: bindings to the part of the code that links against PyTorch (or C++ code that transitively does). Additionally, there remain two more Python packages in npcomp (but outside `torch-mlir`): - `npcomp_torch`: Contains the e2e test framework and testing configs that plug into RefBackend and IREE. - `npcomp_core`: Contains the low-level interfaces to RefBackend and IREE that `npcomp_torch` uses, along with its own `MLIR_PYTHON_PACKAGE_PREFIX=npcomp.` aggregation of the core MLIR python bindings. (all other functionality has been stripped out) After all the basicpy/numpy deletions, the `npcomp` C++ code is now very tiny. It basically just contains RefBackend and the `TorchConversion` dialect/passes (e.g. `TorchToLinalg.cpp`). Correspondingly, there are now 4 main testing targets paralleling the Python layering (which is reflective of the deeper underlying dependency structure) - `check-torch-mlir`: checks the `torch-mlir` pure MLIR C++ code. - `check-torch-mlir-plugin`: checks the code in `TorchPlugin` (e.g. TorchScript import) - `check-frontends-pytorch`: Checks the little code we have in `frontends/pytorch` -- mainly things related to the e2e framework itself. - `check-npcomp`: Checks the pure MLIR C++ code inside npcomp. There is a target `check-npcomp-all` that runs all of them. The `torch-mlir/build_standalone.sh` script does a standalone build of `torch-mlir`. The e2e tests (`tools/torchscript_e2e_test.sh`) are working too. The update_torch_ods script now lives in `torch-mlir/build_tools/update_torch_ods.sh` and expects a standalone build. This change also required a fix upstream related to cross-shlib Python dependencies, so we also update llvm-project to 8dca953dd39c0cd8c80decbeb38753f58a4de580 to get https://reviews.llvm.org/D109776 (no other fixes were needed for the integrate, thankfully). This completes most of the large source code changes. Next will be bringing the CI/packaging/examples back to life.
2021-09-11 02:44:38 +08:00
build_dir="$(realpath "${TORCH_MLIR_BUILD_DIR:-$src_dir/build}")"
Reduce compilation time for TorchOps.cpp.inc The `assemblyFormat` stuff (which generates unrolled, per-op C++ code) was taking up a lot of compile time, and all the ops are essentially printed with the same logic. So this PR makes them all call the same helper function. This is done by using `let hasCustomAssemblyFormat = 1` and then implementing `FooOp::parse` and `FooOp::print`. Additionally, the `Generated*Ops.td` files are all collapsed into just `GeneratedTorchOps.td` (there is no reason to have the files separate, since the files are very large anyway so one is always having to search within them -- editors don't care that the file to search is now a bit bigger :) ). This reduces TorchOpsODSGenerated.cpp compile time (which is now GeneratedTorchOps.cpp) from 39 to 31 seconds on my machine. This is actually less than I expected, but this PR is an overall cleanup to the code anyway. The next step will be to introduce (better) functionality upstream for sharding the TorchOps.cpp.inc file, so that we can truly parallelize the O(#ops) costs. This is also necessary, because after this PR, TorchDialect.cpp is now the slowest file to compile, due to the `addOperations<... all the ops ...>` call, which needs to be shareded too.
2022-03-19 05:04:47 +08:00
torch_ir_include_dir="${src_dir}/include/torch-mlir/Dialect/Torch/IR"
build: enable update scripts to work with out-of-tree builds (#1553) Before this patch, the update_shape_lib.sh and update_torch_ods.sh scripts only worked on in-tree builds, which implied that the RollPyTorch action was forced to run the longer-running in-tree build. As a result of this patch, we should be able to run through the basic checks in the RollPyTorch action faster, while running the full suite of tests off the critical path. The key change in this patch is that the update scripts now look for the directory that is most recently modified between in-tree or out-of-tree build directories. The change also correctly handles the case when only one of the two directories exists.
2022-11-04 21:13:02 +08:00
in_tree_pkg_dir="${build_dir}/tools/torch-mlir/python_packages"
out_of_tree_pkg_dir="${build_dir}/python_packages"
if [[ ! -d "${in_tree_pkg_dir}" && ! -d "${out_of_tree_pkg_dir}" ]]; then
echo "Couldn't find in-tree or out-of-tree build, exiting."
exit 1
fi
# The `-nt` check works even if one of the two directories is missing.
if [[ "${in_tree_pkg_dir}" -nt "${out_of_tree_pkg_dir}" ]]; then
python_packages_dir="${in_tree_pkg_dir}"
else
python_packages_dir="${out_of_tree_pkg_dir}"
fi
[torch-mlir earthmoving (2/N)] Python code movement. This moves the bulk of the Python code (including the Torch interop) from `frontends/pytorch` into `torch-mlir/TorchPlugin`. This also required reconciling a bunch of other Python-related stuff, like the `torch` dialects. As I did this, it was simpler to just remove all the old numpy/basicpy stuff because we were going to delete it anyway and it was faster than debugging an intermediate state that would only last O(days) anyway. torch-mlir has two top-level python packages (built into the `python_packages` directory): - `torch_mlir_dialects`: `torch` dialect Python bindings (does not depend on PyTorch). This also involves building the aggregate CAPI for `torch-mlir`. - `torch_mlir`: bindings to the part of the code that links against PyTorch (or C++ code that transitively does). Additionally, there remain two more Python packages in npcomp (but outside `torch-mlir`): - `npcomp_torch`: Contains the e2e test framework and testing configs that plug into RefBackend and IREE. - `npcomp_core`: Contains the low-level interfaces to RefBackend and IREE that `npcomp_torch` uses, along with its own `MLIR_PYTHON_PACKAGE_PREFIX=npcomp.` aggregation of the core MLIR python bindings. (all other functionality has been stripped out) After all the basicpy/numpy deletions, the `npcomp` C++ code is now very tiny. It basically just contains RefBackend and the `TorchConversion` dialect/passes (e.g. `TorchToLinalg.cpp`). Correspondingly, there are now 4 main testing targets paralleling the Python layering (which is reflective of the deeper underlying dependency structure) - `check-torch-mlir`: checks the `torch-mlir` pure MLIR C++ code. - `check-torch-mlir-plugin`: checks the code in `TorchPlugin` (e.g. TorchScript import) - `check-frontends-pytorch`: Checks the little code we have in `frontends/pytorch` -- mainly things related to the e2e framework itself. - `check-npcomp`: Checks the pure MLIR C++ code inside npcomp. There is a target `check-npcomp-all` that runs all of them. The `torch-mlir/build_standalone.sh` script does a standalone build of `torch-mlir`. The e2e tests (`tools/torchscript_e2e_test.sh`) are working too. The update_torch_ods script now lives in `torch-mlir/build_tools/update_torch_ods.sh` and expects a standalone build. This change also required a fix upstream related to cross-shlib Python dependencies, so we also update llvm-project to 8dca953dd39c0cd8c80decbeb38753f58a4de580 to get https://reviews.llvm.org/D109776 (no other fixes were needed for the integrate, thankfully). This completes most of the large source code changes. Next will be bringing the CI/packaging/examples back to life.
2021-09-11 02:44:38 +08:00
Re-enable custom op support
2022-08-03 04:35:56 +08:00
TORCH_MLIR_EXT_PYTHONPATH="${TORCH_MLIR_EXT_PYTHONPATH:-""}"
Allow torch-mlir to support PyTorch extensions. (#895) PyTorch allows new operators to be registered dynamically in modules. Torch-mlir already makes it fairly straightforward to add support for new operators, and this commit just extends that support to allow new PyTorch ops to come from a external module. This does *not* allow ops to be dynamically loaded into torch-mlir. Torch-mlir must still be compiled with support built-in. Add a `_torch_mlir_custom_op_example` subpackage to `torch_mlir` which registers an demonstration op. It will not be imported by default when importing torch_mlir. It's strictly for testing and documentation. Adds an end-to-end test for the `torch_mlir_custom_op_example::identity` op. With all these changes, we should now be actively testing PyTorch extension support with all future patches.
2022-06-14 05:51:30 +08:00
pypath="${python_packages_dir}/torch_mlir"
Re-enable custom op support
2022-08-03 04:35:56 +08:00
if [ ! -z ${TORCH_MLIR_EXT_PYTHONPATH} ]; then
pypath="${pypath}:${TORCH_MLIR_EXT_PYTHONPATH}"
fi
TORCH_MLIR_EXT_MODULES="${TORCH_MLIR_EXT_MODULES:-""}"
ext_module="${ext_module:-""}"
if [ ! -z ${TORCH_MLIR_EXT_MODULES} ]; then
ext_module="${TORCH_MLIR_EXT_MODULES}"
fi
Allow torch-mlir to support PyTorch extensions. (#895) PyTorch allows new operators to be registered dynamically in modules. Torch-mlir already makes it fairly straightforward to add support for new operators, and this commit just extends that support to allow new PyTorch ops to come from a external module. This does *not* allow ops to be dynamically loaded into torch-mlir. Torch-mlir must still be compiled with support built-in. Add a `_torch_mlir_custom_op_example` subpackage to `torch_mlir` which registers an demonstration op. It will not be imported by default when importing torch_mlir. It's strictly for testing and documentation. Adds an end-to-end test for the `torch_mlir_custom_op_example::identity` op. With all these changes, we should now be actively testing PyTorch extension support with all future patches.
2022-06-14 05:51:30 +08:00
PYTHONPATH="${pypath}" python \
Implement Python relayout from #311 Fixes https://github.com/llvm/mlir-npcomp/issues/311 The key change is that TorchPlugin is folded into `torch_mlir.dialects.torch.importer.jit_ir` (it imports the PyTorch JIT's IR, so that's a good, scoped name for it). The CMake option `-DTORCH_MLIR_ENABLE_JIT_IR_IMPORTER=OFF` disables it, which allows building without a PyTorch native dependency.
2021-09-21 04:55:36 +08:00
-m torch_mlir.dialects.torch.importer.jit_ir.build_tools.torch_ods_gen \
Reduce compilation time for TorchOps.cpp.inc The `assemblyFormat` stuff (which generates unrolled, per-op C++ code) was taking up a lot of compile time, and all the ops are essentially printed with the same logic. So this PR makes them all call the same helper function. This is done by using `let hasCustomAssemblyFormat = 1` and then implementing `FooOp::parse` and `FooOp::print`. Additionally, the `Generated*Ops.td` files are all collapsed into just `GeneratedTorchOps.td` (there is no reason to have the files separate, since the files are very large anyway so one is always having to search within them -- editors don't care that the file to search is now a bit bigger :) ). This reduces TorchOpsODSGenerated.cpp compile time (which is now GeneratedTorchOps.cpp) from 39 to 31 seconds on my machine. This is actually less than I expected, but this PR is an overall cleanup to the code anyway. The next step will be to introduce (better) functionality upstream for sharding the TorchOps.cpp.inc file, so that we can truly parallelize the O(#ops) costs. This is also necessary, because after this PR, TorchDialect.cpp is now the slowest file to compile, due to the `addOperations<... all the ops ...>` call, which needs to be shareded too.
2022-03-19 05:04:47 +08:00
--torch_ir_include_dir="${torch_ir_include_dir}" \
Re-enable custom op support
2022-08-03 04:35:56 +08:00
--pytorch_op_extensions="${ext_module}" \
Reduce compilation time for TorchOps.cpp.inc The `assemblyFormat` stuff (which generates unrolled, per-op C++ code) was taking up a lot of compile time, and all the ops are essentially printed with the same logic. So this PR makes them all call the same helper function. This is done by using `let hasCustomAssemblyFormat = 1` and then implementing `FooOp::parse` and `FooOp::print`. Additionally, the `Generated*Ops.td` files are all collapsed into just `GeneratedTorchOps.td` (there is no reason to have the files separate, since the files are very large anyway so one is always having to search within them -- editors don't care that the file to search is now a bit bigger :) ). This reduces TorchOpsODSGenerated.cpp compile time (which is now GeneratedTorchOps.cpp) from 39 to 31 seconds on my machine. This is actually less than I expected, but this PR is an overall cleanup to the code anyway. The next step will be to introduce (better) functionality upstream for sharding the TorchOps.cpp.inc file, so that we can truly parallelize the O(#ops) costs. This is also necessary, because after this PR, TorchDialect.cpp is now the slowest file to compile, due to the `addOperations<... all the ops ...>` call, which needs to be shareded too.
2022-03-19 05:04:47 +08:00
--debug_registry_dump="${torch_ir_include_dir}/JITOperatorRegistryDump.txt"