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/cmake/TorchMLIRPyTorch.cmake

148 lines
6.4 KiB
CMake
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
# TorchMLIRProbeForPyTorchInstall
Make torch_mlir compatible with binary PyTorch installations. * This has been anticipated for a long time in that it is quite hard to keep C++ binary compatibility across a system landscape as diverse as PyTorch, LLVM, and this project. This is why we based the PyTorch extension on the MLIR and NPCOMP C APIs only: that is the only sane linkage story for the entire matrix. * Removes the few LLVM'isms in torch_mlir that had snuck in, using either STL or PyTorch support utilities. The new rule here is that LLVM C++ includes are forbidden at this level and (as stated in the design), torch_mlir should use the PyTorch runtime and support libraries (not introduce an incidental C++ dependency on LLVM). * Also deletes mnist-playground as it was proving impossible to keep the grid of PyTorch vs system ABI divisions functioning. I am open to a less drastic course here (optional/disabled by default?) * This gets us pretty close to just using PyTorch's extension builder API, which will be nice for distribution (i.e. it integrates well with the PyTorch ecosystem for deployment). I ended up just simplifying the in-tree CMake support for now. * Fixes #138
2020-12-15 00:42:42 +08:00
# Attempts to find a Torch installation and set the Torch_ROOT variable
# based on introspecting the python environment. This allows a subsequent
# call to find_package(Torch) to work.
[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
function(TorchMLIRProbeForPyTorchInstall)
Teach cmake how to find the installed PyTorch. * In most situations, this eliminates the need to explicitly set a path to the Torch cmake files. * Also upgrades to new Python3 find package. (should eliminate 2.x mismatches) * Since PyTorch is located by asking Python where it is, this eliminates a lot of causes of mismatch. (one source of truth)
2020-11-14 08:07:57 +08:00
if(Torch_ROOT)
message(STATUS "Using cached Torch root = ${Torch_ROOT}")
else()
Rework the python build to a static assembly of MLIR+NPCOMP (#251) * Adapt to python build system updates. * Bump llvm to 310c9496d80961188e8d8f8ad306cdf44bd7541f (includes python build updates) * Adds refback C-API. * Re-layers all python builds. * Rework CI.
2021-07-28 07:10:10 +08:00
message(STATUS "Checking for PyTorch using ${Python3_EXECUTABLE} ...")
Teach cmake how to find the installed PyTorch. * In most situations, this eliminates the need to explicitly set a path to the Torch cmake files. * Also upgrades to new Python3 find package. (should eliminate 2.x mismatches) * Since PyTorch is located by asking Python where it is, this eliminates a lot of causes of mismatch. (one source of truth)
2020-11-14 08:07:57 +08:00
execute_process(
Rework the python build to a static assembly of MLIR+NPCOMP (#251) * Adapt to python build system updates. * Bump llvm to 310c9496d80961188e8d8f8ad306cdf44bd7541f (includes python build updates) * Adds refback C-API. * Re-layers all python builds. * Rework CI.
2021-07-28 07:10:10 +08:00
COMMAND ${Python3_EXECUTABLE}
Make torch_mlir compatible with binary PyTorch installations. * This has been anticipated for a long time in that it is quite hard to keep C++ binary compatibility across a system landscape as diverse as PyTorch, LLVM, and this project. This is why we based the PyTorch extension on the MLIR and NPCOMP C APIs only: that is the only sane linkage story for the entire matrix. * Removes the few LLVM'isms in torch_mlir that had snuck in, using either STL or PyTorch support utilities. The new rule here is that LLVM C++ includes are forbidden at this level and (as stated in the design), torch_mlir should use the PyTorch runtime and support libraries (not introduce an incidental C++ dependency on LLVM). * Also deletes mnist-playground as it was proving impossible to keep the grid of PyTorch vs system ABI divisions functioning. I am open to a less drastic course here (optional/disabled by default?) * This gets us pretty close to just using PyTorch's extension builder API, which will be nice for distribution (i.e. it integrates well with the PyTorch ecosystem for deployment). I ended up just simplifying the in-tree CMake support for now. * Fixes #138
2020-12-15 00:42:42 +08:00
-c "import os;import torch;print(torch.utils.cmake_prefix_path, end='')"
Teach cmake how to find the installed PyTorch. * In most situations, this eliminates the need to explicitly set a path to the Torch cmake files. * Also upgrades to new Python3 find package. (should eliminate 2.x mismatches) * Since PyTorch is located by asking Python where it is, this eliminates a lot of causes of mismatch. (one source of truth)
2020-11-14 08:07:57 +08:00
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
RESULT_VARIABLE PYTORCH_STATUS
OUTPUT_VARIABLE PYTORCH_PACKAGE_DIR)
if(NOT PYTORCH_STATUS EQUAL "0")
Rework the python build to a static assembly of MLIR+NPCOMP (#251) * Adapt to python build system updates. * Bump llvm to 310c9496d80961188e8d8f8ad306cdf44bd7541f (includes python build updates) * Adds refback C-API. * Re-layers all python builds. * Rework CI.
2021-07-28 07:10:10 +08:00
message(STATUS "Unable to 'import torch' with ${Python3_EXECUTABLE} (fallback to explicit config)")
Teach cmake how to find the installed PyTorch. * In most situations, this eliminates the need to explicitly set a path to the Torch cmake files. * Also upgrades to new Python3 find package. (should eliminate 2.x mismatches) * Since PyTorch is located by asking Python where it is, this eliminates a lot of causes of mismatch. (one source of truth)
2020-11-14 08:07:57 +08:00
return()
endif()
message(STATUS "Found PyTorch installation at ${PYTORCH_PACKAGE_DIR}")
Make torch_mlir compatible with binary PyTorch installations. * This has been anticipated for a long time in that it is quite hard to keep C++ binary compatibility across a system landscape as diverse as PyTorch, LLVM, and this project. This is why we based the PyTorch extension on the MLIR and NPCOMP C APIs only: that is the only sane linkage story for the entire matrix. * Removes the few LLVM'isms in torch_mlir that had snuck in, using either STL or PyTorch support utilities. The new rule here is that LLVM C++ includes are forbidden at this level and (as stated in the design), torch_mlir should use the PyTorch runtime and support libraries (not introduce an incidental C++ dependency on LLVM). * Also deletes mnist-playground as it was proving impossible to keep the grid of PyTorch vs system ABI divisions functioning. I am open to a less drastic course here (optional/disabled by default?) * This gets us pretty close to just using PyTorch's extension builder API, which will be nice for distribution (i.e. it integrates well with the PyTorch ecosystem for deployment). I ended up just simplifying the in-tree CMake support for now. * Fixes #138
2020-12-15 00:42:42 +08:00
set(Torch_ROOT "${PYTORCH_PACKAGE_DIR}" CACHE STRING
"Torch configure directory" FORCE)
endif()
endfunction()
[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
# TorchMLIRConfigurePyTorch
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
# Extensions compiled against PyTorch must be ABI-compatible with PyTorch.
# On Linux, there are two components to this:
# 1) Dual ABI settings for libstdc++
# See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
# For this, PyTorch helpfully provides a function to check which ABI it was
# compiled against.
# 2) C++ ABI compatibility version
# See https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html (Sec 5/6)
# The second is a bit more complicated. GCC has official compatibility strings
# which can be specified by -fabi-version. Clang has no notion of ABI
# versioning (https://lists.llvm.org/pipermail/cfe-dev/2015-June/043735.html).
# Separately, pybind11 keeps an internal variable which records its ABI info
# (PYBIND11_INTERNALS_ID in include/pybind11/detail/internals.h). Differences
# in this variable between torch-mlir and PyTorch will cause type errors.
# Thus, our best option is to:
# a) Identify which ABI version PyTorch was compiled with
# b) Tell gcc to use that version
# or
# c) Tell clang to pretend to use it and hope it's ABI-compatible, and
# tell pybind to pretend we're gcc.
#
# MacOS does not have a dual ABI problem.
# FIXME: I don't know if MacOS needs ABI compatibility version flags.
Make torch_mlir compatible with binary PyTorch installations. * This has been anticipated for a long time in that it is quite hard to keep C++ binary compatibility across a system landscape as diverse as PyTorch, LLVM, and this project. This is why we based the PyTorch extension on the MLIR and NPCOMP C APIs only: that is the only sane linkage story for the entire matrix. * Removes the few LLVM'isms in torch_mlir that had snuck in, using either STL or PyTorch support utilities. The new rule here is that LLVM C++ includes are forbidden at this level and (as stated in the design), torch_mlir should use the PyTorch runtime and support libraries (not introduce an incidental C++ dependency on LLVM). * Also deletes mnist-playground as it was proving impossible to keep the grid of PyTorch vs system ABI divisions functioning. I am open to a less drastic course here (optional/disabled by default?) * This gets us pretty close to just using PyTorch's extension builder API, which will be nice for distribution (i.e. it integrates well with the PyTorch ecosystem for deployment). I ended up just simplifying the in-tree CMake support for now. * Fixes #138
2020-12-15 00:42:42 +08:00
#
# In the future, we may want to switch away from custom building these
# extensions and instead rely on the Torch machinery directly (definitely want
# to do that for official builds).
[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
function(TorchMLIRConfigurePyTorch)
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
message(STATUS "Checking PyTorch ABI settings...")
Make torch_mlir compatible with binary PyTorch installations. * This has been anticipated for a long time in that it is quite hard to keep C++ binary compatibility across a system landscape as diverse as PyTorch, LLVM, and this project. This is why we based the PyTorch extension on the MLIR and NPCOMP C APIs only: that is the only sane linkage story for the entire matrix. * Removes the few LLVM'isms in torch_mlir that had snuck in, using either STL or PyTorch support utilities. The new rule here is that LLVM C++ includes are forbidden at this level and (as stated in the design), torch_mlir should use the PyTorch runtime and support libraries (not introduce an incidental C++ dependency on LLVM). * Also deletes mnist-playground as it was proving impossible to keep the grid of PyTorch vs system ABI divisions functioning. I am open to a less drastic course here (optional/disabled by default?) * This gets us pretty close to just using PyTorch's extension builder API, which will be nice for distribution (i.e. it integrates well with the PyTorch ecosystem for deployment). I ended up just simplifying the in-tree CMake support for now. * Fixes #138
2020-12-15 00:42:42 +08:00
if(${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
# Check dual ABI setting first
Make torch_mlir compatible with binary PyTorch installations. * This has been anticipated for a long time in that it is quite hard to keep C++ binary compatibility across a system landscape as diverse as PyTorch, LLVM, and this project. This is why we based the PyTorch extension on the MLIR and NPCOMP C APIs only: that is the only sane linkage story for the entire matrix. * Removes the few LLVM'isms in torch_mlir that had snuck in, using either STL or PyTorch support utilities. The new rule here is that LLVM C++ includes are forbidden at this level and (as stated in the design), torch_mlir should use the PyTorch runtime and support libraries (not introduce an incidental C++ dependency on LLVM). * Also deletes mnist-playground as it was proving impossible to keep the grid of PyTorch vs system ABI divisions functioning. I am open to a less drastic course here (optional/disabled by default?) * This gets us pretty close to just using PyTorch's extension builder API, which will be nice for distribution (i.e. it integrates well with the PyTorch ecosystem for deployment). I ended up just simplifying the in-tree CMake support for now. * Fixes #138
2020-12-15 00:42:42 +08:00
execute_process(
Rework the python build to a static assembly of MLIR+NPCOMP (#251) * Adapt to python build system updates. * Bump llvm to 310c9496d80961188e8d8f8ad306cdf44bd7541f (includes python build updates) * Adds refback C-API. * Re-layers all python builds. * Rework CI.
2021-07-28 07:10:10 +08:00
COMMAND ${Python3_EXECUTABLE}
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
-c "import torch; import sys; sys.stdout.write('1' if torch.compiled_with_cxx11_abi() else '0')"
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
RESULT_VARIABLE _result
Make torch_mlir compatible with binary PyTorch installations. * This has been anticipated for a long time in that it is quite hard to keep C++ binary compatibility across a system landscape as diverse as PyTorch, LLVM, and this project. This is why we based the PyTorch extension on the MLIR and NPCOMP C APIs only: that is the only sane linkage story for the entire matrix. * Removes the few LLVM'isms in torch_mlir that had snuck in, using either STL or PyTorch support utilities. The new rule here is that LLVM C++ includes are forbidden at this level and (as stated in the design), torch_mlir should use the PyTorch runtime and support libraries (not introduce an incidental C++ dependency on LLVM). * Also deletes mnist-playground as it was proving impossible to keep the grid of PyTorch vs system ABI divisions functioning. I am open to a less drastic course here (optional/disabled by default?) * This gets us pretty close to just using PyTorch's extension builder API, which will be nice for distribution (i.e. it integrates well with the PyTorch ecosystem for deployment). I ended up just simplifying the in-tree CMake support for now. * Fixes #138
2020-12-15 00:42:42 +08:00
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
OUTPUT_VARIABLE _use_cxx11_abi)
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
if(_result)
message(FATAL_ERROR "Failed to determine C++ Dual ABI")
endif()
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
message(STATUS "PyTorch C++ Dual ABI setting: \"${_use_cxx11_abi}\"")
# Check ABI compatibility version
execute_process(
COMMAND ${Python3_EXECUTABLE}
-c "import torch; import sys; abi=torch._C._PYBIND11_BUILD_ABI; abi.startswith('_cxxabi10') or sys.exit(1); sys.stdout.write(str(abi[-2:]))"
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
RESULT_VARIABLE _result
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
OUTPUT_VARIABLE _cxx_abi_version)
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
if(_result)
message(FATAL_ERROR "Failed to determine C++ ABI version")
endif()
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
message(STATUS "PyTorch C++ ABI version: \"${_cxx_abi_version}\"")
# Specialize compile flags for compiler
Link against libtorch (#955) This moves torch-mlir to link against libtorch on macOS and linux TESTS: Tests pass. Tested release builds on linux and macOS
2022-07-01 03:40:17 +08:00
if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
set(TORCH_CXXFLAGS "-D_GLIBCXX_USE_CXX11_ABI=${_use_cxx11_abi} -fabi-version=${_cxx_abi_version}")
elseif(${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
set(TORCH_CXXFLAGS "-D_GLIBCXX_USE_CXX11_ABI=${_use_cxx11_abi} -U__GXX_ABI_VERSION -D__GXX_ABI_VERSION=10${_cxx_abi_version} '-DPYBIND11_COMPILER_TYPE=\"_gcc\"'")
else()
message(WARNING "Unrecognized compiler. Cannot determine ABI flags.")
return()
endif()
set(TORCH_CXXFLAGS "${TORCH_CXXFLAGS}" PARENT_SCOPE)
endif()
endfunction()
function(TorchMLIRConfigureLibTorch)
message(STATUS "Checking LibTorch ABI settings...")
if(${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
message(STATUS "libtorch_python is ${TORCH_INSTALL_PREFIX}/lib/libtorch_python.so")
# Check dual ABI setting first
execute_process(
COMMAND bash "-c" "cat ${TORCH_INSTALL_PREFIX}/share/cmake/Torch/TorchConfig.cmake | egrep -o '_GLIBCXX_USE_CXX11_ABI=[0-1]' | egrep -o '.$'"
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
RESULT_VARIABLE _result
Link against libtorch (#955) This moves torch-mlir to link against libtorch on macOS and linux TESTS: Tests pass. Tested release builds on linux and macOS
2022-07-01 03:40:17 +08:00
OUTPUT_VARIABLE _use_cxx11_abi
OUTPUT_STRIP_TRAILING_WHITESPACE)
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
if(_result)
message(FATAL_ERROR "Failed to determine LibTorch C++ Dual ABI")
endif()
Link against libtorch (#955) This moves torch-mlir to link against libtorch on macOS and linux TESTS: Tests pass. Tested release builds on linux and macOS
2022-07-01 03:40:17 +08:00
message(STATUS "LibTorch C++ Dual ABI setting: \"${_use_cxx11_abi}\"")
# Check ABI compatibility version
execute_process(
COMMAND bash "-c" "strings ${TORCH_INSTALL_PREFIX}/lib/libtorch_python.so | egrep '^_cxxabi[0-9]{4}' | egrep -o '..$'"
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
RESULT_VARIABLE _result
Link against libtorch (#955) This moves torch-mlir to link against libtorch on macOS and linux TESTS: Tests pass. Tested release builds on linux and macOS
2022-07-01 03:40:17 +08:00
OUTPUT_VARIABLE _cxx_abi_version
OUTPUT_STRIP_TRAILING_WHITESPACE)
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
if(_result)
message(FATAL_ERROR "Failed to determine LibTorch C++ ABI version")
endif()
Link against libtorch (#955) This moves torch-mlir to link against libtorch on macOS and linux TESTS: Tests pass. Tested release builds on linux and macOS
2022-07-01 03:40:17 +08:00
message(STATUS "LibTorch C++ ABI version: \"${_cxx_abi_version}\"")
# Specialize compile flags for compiler
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
set(TORCH_CXXFLAGS "-D_GLIBCXX_USE_CXX11_ABI=${_use_cxx11_abi} -fabi-version=${_cxx_abi_version}")
elseif(${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
set(TORCH_CXXFLAGS "-D_GLIBCXX_USE_CXX11_ABI=${_use_cxx11_abi} -U__GXX_ABI_VERSION -D__GXX_ABI_VERSION=10${_cxx_abi_version} '-DPYBIND11_COMPILER_TYPE=\"_gcc\"'")
else()
message(WARNING "Unrecognized compiler. Cannot determine ABI flags.")
return()
Make torch_mlir compatible with binary PyTorch installations. * This has been anticipated for a long time in that it is quite hard to keep C++ binary compatibility across a system landscape as diverse as PyTorch, LLVM, and this project. This is why we based the PyTorch extension on the MLIR and NPCOMP C APIs only: that is the only sane linkage story for the entire matrix. * Removes the few LLVM'isms in torch_mlir that had snuck in, using either STL or PyTorch support utilities. The new rule here is that LLVM C++ includes are forbidden at this level and (as stated in the design), torch_mlir should use the PyTorch runtime and support libraries (not introduce an incidental C++ dependency on LLVM). * Also deletes mnist-playground as it was proving impossible to keep the grid of PyTorch vs system ABI divisions functioning. I am open to a less drastic course here (optional/disabled by default?) * This gets us pretty close to just using PyTorch's extension builder API, which will be nice for distribution (i.e. it integrates well with the PyTorch ecosystem for deployment). I ended up just simplifying the in-tree CMake support for now. * Fixes #138
2020-12-15 00:42:42 +08:00
endif()
Expand checks against PyTorch C++ ABI settings. (#777) Compiling torch-mlir against a source version of PyTorch or an official wheel compiled with the new C++ stdlib ABI fails, as torch-mlir doesn't know how to set compiler flags to remain compatible. This changes the way torch-mlir looks at PyTorch and tries to more closely match the ABI settings, regardless of whether it's the common official wheel or some other version.
2022-04-28 01:44:46 +08:00
set(TORCH_CXXFLAGS "${TORCH_CXXFLAGS}" PARENT_SCOPE)
Teach cmake how to find the installed PyTorch. * In most situations, this eliminates the need to explicitly set a path to the Torch cmake files. * Also upgrades to new Python3 find package. (should eliminate 2.x mismatches) * Since PyTorch is located by asking Python where it is, this eliminates a lot of causes of mismatch. (one source of truth)
2020-11-14 08:07:57 +08:00
endif()
endfunction()
[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
function(torch_mlir_python_target_compile_options target)
target_compile_options(${target} PRIVATE
$<$<OR:$<CXX_COMPILER_ID:Clang>,$<CXX_COMPILER_ID:AppleClang>,$<CXX_COMPILER_ID:GNU>>:
# Enable RTTI and exceptions.
-frtti -fexceptions
# Noisy pybind warnings
-Wno-unused-value
-Wno-covered-switch-default
>
$<$<CXX_COMPILER_ID:MSVC>:
# Enable RTTI and exceptions.
/EHsc /GR>
)
endfunction()