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

213 lines
8.0 KiB
CMake
Raw Normal View History

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
cmake_minimum_required(VERSION 3.12)
Adapt to use installed MLIR
2020-04-27 07:26:45 +08:00
if(POLICY CMP0068)
cmake_policy(SET CMP0068 NEW)
set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
endif()
if(POLICY CMP0075)
cmake_policy(SET CMP0075 NEW)
endif()
if(POLICY CMP0077)
cmake_policy(SET CMP0077 NEW)
endif()
Add initial support for taking a dep on IREE. * This won't work for most people until some upstream changes percolate. * Sequestered it behind a flag and a special configure script (cmake_configure_iree.sh) for now.
2020-06-12 07:40:31 +08:00
#-------------------------------------------------------------------------------
# Options and settings
#-------------------------------------------------------------------------------
option(NPCOMP_ENABLE_IREE "Enables the IREE backend (must configure location via IREE_DIR)." OFF)
Initial python plumbing to interface with the refjit backend.
2020-07-11 08:36:32 +08:00
option(NPCOMP_ENABLE_REFJIT "Enables the reference JIT backend." ON)
Start reworking towards a shared library build. * Need to have a dag of shared library deps in order to interop across python extensions (as presented in ODM). * Introduced add_npcomp_library and friends to mirror the MLIR setup. * Adds a libNPCOMP.so shared library. * Redirects tools and extensions to link against libNPCOMP.so (instead of static libs). * Moves all libraries to lib/, all binaries to bin/ and all python extensions to python/. The invariant is that the rpaths are setup to have a one level directory structure. * Reworks the _torch_mlir extension to build like the others (still need to come up with a consolidated rule to do this instead of open coded). * Includes an upstream version bump to pick up needed changes. Sizes with dynamic linking (stripped, release, asserts enabled): libNPCOMP.so: 43M (includes much of the underlying LLVM codegen deps) libMLIR.so: 31M _npcomp.so: 1.6M (python extension) _torch_mlir.so: 670K (python extension) npcomp-capi-ir-test: 6.3K npcomp-opt: 351K npcomp-run-mlir: 461K mnist-playground: 530K Still more can be done to normalize and optimize but this gets us structurally to the starting point.
2020-10-09 09:29:59 +08:00
option(NPCOMP_BUILD_NPCOMP_DYLIB "Enables shared build of NPCOMP dylib (depends on LLVM/MLIR dylib support)" ON)
Sever C++ level depend on IREE and rebase on exe and python interface. * IREE doesn't have proper install support, so there is some temporary hoaky hacking in our CMakeLists.txt to shuttle some symlinks around. * Reworked the original numpy e2e with IREE test to pipe through iree-translate. * Removed all of the C++-level dependencies. * Will generalize and apply to the PyTorch backend in a followup.
2020-11-14 10:06:59 +08:00
set(NPCOMP_IREE_BUILDDIR "../iree-build" CACHE STRING "If building IREE, then setting this elects to build from a source directory (versus installed package)")
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
set(NPCOMP_ENABLE_PYTORCH "OPTIONAL" CACHE STRING "Enables the PyTorch frontend (OFF, OPTIONAL, REQUIRED)")
Add initial support for taking a dep on IREE. * This won't work for most people until some upstream changes percolate. * Sequestered it behind a flag and a special configure script (cmake_configure_iree.sh) for now.
2020-06-12 07:40:31 +08:00
Tweak build flags for efficiency and document building without a container. * Enables -gsplit-dwarf for both LLVM and NPCOMP, reducing the occurrence of the ~GB scale binaries. * CMake shared linking seems incompatible with this, so shared objects are still "too big" but there are few of them. * Reduces disk thrash on clean/install of everything.
2020-11-04 05:46:46 +08:00
# Turn on -gsplit-dwarf if requested in debug builds.
if (NPCOMP_USE_SPLIT_DWARF AND
((CMAKE_BUILD_TYPE STREQUAL "Debug") OR
(CMAKE_BUILD_TYPE STREQUAL "RelWithDebInfo")))
# Limit to clang and gcc so far. Add compilers supporting this option.
if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" OR
CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
add_compile_options(-gsplit-dwarf)
endif()
endif()
Some fixes to get npcomp building and passing on windows. There is more that can be done here, but this gets it minimally working.
2020-07-02 12:28:04 +08:00
#-------------------------------------------------------------------------------
# MSVC defaults
#-------------------------------------------------------------------------------
if(MSVC)
add_compile_options(
$<$<CONFIG:>:/MD>
$<$<CONFIG:Debug>:/MD>
$<$<CONFIG:Release>:/MD>
)
endif()
Enable building using LLVM_EXTERNAL_PROJECTS. (#152) This allows building NPCOMP as an external project of LLVM, similar to how CIRCT can be built: https://github.com/llvm/circt/pull/227. The CMake options to use this build style look like this: ``` -DLLVM_EXTERNAL_PROJECTS=npcomp \ -DLLVM_EXTERNAL_NPCOMP_SOURCE_DIR=/path/to/mlir-npcomp \ ```
2021-01-27 02:43:43 +08:00
if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
# If we are not building as a part of LLVM, build NPCOMP as a standalone
# project, using LLVM as an external library.
#-------------------------------------------------------------------------------
# Project setup and globals
#-------------------------------------------------------------------------------
project(npcomp LANGUAGES CXX C)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 14)
Adapt to use installed MLIR
2020-04-27 07:26:45 +08:00
Enable building using LLVM_EXTERNAL_PROJECTS. (#152) This allows building NPCOMP as an external project of LLVM, similar to how CIRCT can be built: https://github.com/llvm/circt/pull/227. The CMake options to use this build style look like this: ``` -DLLVM_EXTERNAL_PROJECTS=npcomp \ -DLLVM_EXTERNAL_NPCOMP_SOURCE_DIR=/path/to/mlir-npcomp \ ```
2021-01-27 02:43:43 +08:00
#-------------------------------------------------------------------------------
# MLIR/LLVM Configuration
#-------------------------------------------------------------------------------
[cmake] Updates for basic shared library support (#7) Mostly this is CMake cleanup. Several library dependencies are missing, which is often revealed with shared library builds. Also, it's generally bad to link directly against LLVM libraries because it fails when using LLVM_LINK_LLVM_DYLIB. MLIR will pull in libLLVM.so, and there will be duplicate linkage with the the explicit libraries. There may need to be more refactoring here.
2020-08-06 05:49:18 +08:00
Enable building using LLVM_EXTERNAL_PROJECTS. (#152) This allows building NPCOMP as an external project of LLVM, similar to how CIRCT can be built: https://github.com/llvm/circt/pull/227. The CMake options to use this build style look like this: ``` -DLLVM_EXTERNAL_PROJECTS=npcomp \ -DLLVM_EXTERNAL_NPCOMP_SOURCE_DIR=/path/to/mlir-npcomp \ ```
2021-01-27 02:43:43 +08:00
find_package(MLIR REQUIRED CONFIG)
message(STATUS "Using MLIRConfig.cmake in: ${MLIR_DIR}")
message(STATUS "Using LLVMConfig.cmake in: ${LLVM_DIR}")
[cmake] Updates for basic shared library support (#7) Mostly this is CMake cleanup. Several library dependencies are missing, which is often revealed with shared library builds. Also, it's generally bad to link directly against LLVM libraries because it fails when using LLVM_LINK_LLVM_DYLIB. MLIR will pull in libLLVM.so, and there will be duplicate linkage with the the explicit libraries. There may need to be more refactoring here.
2020-08-06 05:49:18 +08:00
Enable building using LLVM_EXTERNAL_PROJECTS. (#152) This allows building NPCOMP as an external project of LLVM, similar to how CIRCT can be built: https://github.com/llvm/circt/pull/227. The CMake options to use this build style look like this: ``` -DLLVM_EXTERNAL_PROJECTS=npcomp \ -DLLVM_EXTERNAL_NPCOMP_SOURCE_DIR=/path/to/mlir-npcomp \ ```
2021-01-27 02:43:43 +08:00
#set(LLVM_RUNTIME_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/bin)
set(LLVM_LIBRARY_OUTPUT_INTDIR ${CMAKE_BINARY_DIR}/lib)
# Define the default arguments to use with 'lit', and an option for the user to
# override.
set(LIT_ARGS_DEFAULT "-sv")
if (MSVC_IDE OR XCODE)
set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --no-progress-bar")
endif()
set(LLVM_LIT_ARGS "${LIT_ARGS_DEFAULT}" CACHE STRING "Default options for lit")
list(APPEND CMAKE_MODULE_PATH "${MLIR_CMAKE_DIR}")
list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_DIR}")
include(TableGen)
include(AddLLVM)
include(AddMLIR)
include(HandleLLVMOptions)
set(NPCOMP_BUILT_STANDALONE 1)
set(BACKEND_PACKAGE_STRING "LLVM ${LLVM_PACKAGE_VERSION}")
else()
# Otherwise, we are building as a part of LLVM, and we need to set up some
# variables and includes.
set(MLIR_MAIN_SRC_DIR ${LLVM_MAIN_SRC_DIR}/../mlir/include ) # --src-root
set(MLIR_INCLUDE_DIR ${LLVM_MAIN_SRC_DIR}/../mlir/include ) # --includedir
set(MLIR_TABLEGEN_OUTPUT_DIR ${CMAKE_BINARY_DIR}/tools/mlir/include)
set(MLIR_TABLEGEN_EXE $<TARGET_FILE:mlir-tblgen>)
include_directories(SYSTEM ${MLIR_INCLUDE_DIR})
include_directories(SYSTEM ${MLIR_TABLEGEN_OUTPUT_DIR})
set(BACKEND_PACKAGE_STRING "${PACKAGE_STRING}")
[cmake] Updates for basic shared library support (#7) Mostly this is CMake cleanup. Several library dependencies are missing, which is often revealed with shared library builds. Also, it's generally bad to link directly against LLVM libraries because it fails when using LLVM_LINK_LLVM_DYLIB. MLIR will pull in libLLVM.so, and there will be duplicate linkage with the the explicit libraries. There may need to be more refactoring here.
2020-08-06 05:49:18 +08:00
endif()
Enable building using LLVM_EXTERNAL_PROJECTS. (#152) This allows building NPCOMP as an external project of LLVM, similar to how CIRCT can be built: https://github.com/llvm/circt/pull/227. The CMake options to use this build style look like this: ``` -DLLVM_EXTERNAL_PROJECTS=npcomp \ -DLLVM_EXTERNAL_NPCOMP_SOURCE_DIR=/path/to/mlir-npcomp \ ```
2021-01-27 02:43:43 +08:00
list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules")
Start reworking towards a shared library build. * Need to have a dag of shared library deps in order to interop across python extensions (as presented in ODM). * Introduced add_npcomp_library and friends to mirror the MLIR setup. * Adds a libNPCOMP.so shared library. * Redirects tools and extensions to link against libNPCOMP.so (instead of static libs). * Moves all libraries to lib/, all binaries to bin/ and all python extensions to python/. The invariant is that the rpaths are setup to have a one level directory structure. * Reworks the _torch_mlir extension to build like the others (still need to come up with a consolidated rule to do this instead of open coded). * Includes an upstream version bump to pick up needed changes. Sizes with dynamic linking (stripped, release, asserts enabled): libNPCOMP.so: 43M (includes much of the underlying LLVM codegen deps) libMLIR.so: 31M _npcomp.so: 1.6M (python extension) _torch_mlir.so: 670K (python extension) npcomp-capi-ir-test: 6.3K npcomp-opt: 351K npcomp-run-mlir: 461K mnist-playground: 530K Still more can be done to normalize and optimize but this gets us structurally to the starting point.
2020-10-09 09:29:59 +08:00
include(AddNPCOMP)
Bump llvm-project to f4f8a67aaf13bc66a2b7d55561b14a3724a5e0de. * Incorporates source fixes. * Uses upstream pybind11 detection logic. * Patches CI. * This may break the CI, which will need to be fixed manually in a followup.
2020-11-23 05:01:15 +08:00
include(NpcompDetectPythonEnv)
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
include(ConfigurePyTorch)
Adapt to use installed MLIR
2020-04-27 07:26:45 +08:00
include_directories(${LLVM_INCLUDE_DIRS})
include_directories(${MLIR_INCLUDE_DIRS})
Enable building using LLVM_EXTERNAL_PROJECTS. (#152) This allows building NPCOMP as an external project of LLVM, similar to how CIRCT can be built: https://github.com/llvm/circt/pull/227. The CMake options to use this build style look like this: ``` -DLLVM_EXTERNAL_PROJECTS=npcomp \ -DLLVM_EXTERNAL_NPCOMP_SOURCE_DIR=/path/to/mlir-npcomp \ ```
2021-01-27 02:43:43 +08:00
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include)
include_directories(${CMAKE_CURRENT_BINARY_DIR}/include)
Adapt to use installed MLIR
2020-04-27 07:26:45 +08:00
link_directories(${LLVM_BUILD_LIBRARY_DIR})
add_definitions(${LLVM_DEFINITIONS})
Basicpy conversion to IREE+std skeleton and first conversions. * Conversions to std for numeric binary expressions, numeric to_boolean, and numeric comparisons. * Added folders to constant ops to comply with requirements of the pass system. * Extended the frontend with parameter/result annotation processing for primitives (can specify types for function arguments). * Added (empty) directory/sources for IREEVM conversions. These are only enabled if IREE is enabled.
2020-06-14 14:45:43 +08:00
set(NPCOMP_TABLEGEN_ARGS "")
Adapt to use installed MLIR
2020-04-27 07:26:45 +08:00
Initial python plumbing to interface with the refjit backend.
2020-07-11 08:36:32 +08:00
#-------------------------------------------------------------------------------
# Optional feature selection
#-------------------------------------------------------------------------------
if(NPCOMP_ENABLE_REFJIT)
add_compile_definitions(NPCOMP_ENABLE_REFJIT)
message(STATUS "Reference JIT backend enabled")
endif()
Add initial support for taking a dep on IREE. * This won't work for most people until some upstream changes percolate. * Sequestered it behind a flag and a special configure script (cmake_configure_iree.sh) for now.
2020-06-12 07:40:31 +08:00
#-------------------------------------------------------------------------------
# IREE configuration
#-------------------------------------------------------------------------------
Make a real library for InitAll and extend it to conditionally initialize dependencies. * Conditioned on the top level CMake option to enable IREE. * There is still some warning flags and such that need triage, but it does build/work.
2020-06-12 08:47:14 +08:00
if(NPCOMP_ENABLE_IREE)
Add initial support for taking a dep on IREE. * This won't work for most people until some upstream changes percolate. * Sequestered it behind a flag and a special configure script (cmake_configure_iree.sh) for now.
2020-06-12 07:40:31 +08:00
add_compile_definitions(NPCOMP_ENABLE_IREE)
Basicpy conversion to IREE+std skeleton and first conversions. * Conversions to std for numeric binary expressions, numeric to_boolean, and numeric comparisons. * Added folders to constant ops to comply with requirements of the pass system. * Extended the frontend with parameter/result annotation processing for primitives (can specify types for function arguments). * Added (empty) directory/sources for IREEVM conversions. These are only enabled if IREE is enabled.
2020-06-14 14:45:43 +08:00
string(APPEND NPCOMP_TABLEGEN_ARGS "-DNPCOMP_ENABLE_IREE")
Sever C++ level depend on IREE and rebase on exe and python interface. * IREE doesn't have proper install support, so there is some temporary hoaky hacking in our CMakeLists.txt to shuttle some symlinks around. * Reworked the original numpy e2e with IREE test to pipe through iree-translate. * Removed all of the C++-level dependencies. * Will generalize and apply to the PyTorch backend in a followup.
2020-11-14 10:06:59 +08:00
if(NPCOMP_IREE_BUILDDIR)
message(STATUS "Depending on IREE build: ${NPCOMP_IREE_BUILDDIR}")
set(IREE_DIR "${NPCOMP_IREE_BUILDDIR}")
set(IREE_FOUND 1)
Add initial support for taking a dep on IREE. * This won't work for most people until some upstream changes percolate. * Sequestered it behind a flag and a special configure script (cmake_configure_iree.sh) for now.
2020-06-12 07:40:31 +08:00
else()
find_package(IREE REQUIRED CONFIG)
endif()
Make a real library for InitAll and extend it to conditionally initialize dependencies. * Conditioned on the top level CMake option to enable IREE. * There is still some warning flags and such that need triage, but it does build/work.
2020-06-12 08:47:14 +08:00
Sever C++ level depend on IREE and rebase on exe and python interface. * IREE doesn't have proper install support, so there is some temporary hoaky hacking in our CMakeLists.txt to shuttle some symlinks around. * Reworked the original numpy e2e with IREE test to pipe through iree-translate. * Removed all of the C++-level dependencies. * Will generalize and apply to the PyTorch backend in a followup.
2020-11-14 10:06:59 +08:00
# This is temporary until IREE properly supports installation. We splice
# the various files into where we want them.
function(symlink_iree src dst)
set(full_src_path "${IREE_DIR}/${src}")
get_filename_component(full_src_path "${full_src_path}" ABSOLUTE)
set(full_dst_path "${CMAKE_CURRENT_BINARY_DIR}/${dst}")
get_filename_component(dst_dir ${full_dst_path} PATH)
file(MAKE_DIRECTORY "${dst_dir}")
execute_process(
COMMAND
${CMAKE_COMMAND} -E create_symlink "${full_src_path}" "${full_dst_path}"
RESULT_VARIABLE result
)
if(NOT ${result} EQUAL 0)
message(FATAL_ERROR "Could not symlink iree file: ${full_src_path} -> ${full_dst_path}")
endif()
endfunction()
symlink_iree(iree/tools/iree-translate python/npcomp/compiler/generic/backend/iree-translate)
symlink_iree(bindings/python/pyiree/rt python/pyiree/rt)
Add initial support for taking a dep on IREE. * This won't work for most people until some upstream changes percolate. * Sequestered it behind a flag and a special configure script (cmake_configure_iree.sh) for now.
2020-06-12 07:40:31 +08:00
endif()
#-------------------------------------------------------------------------------
# Python Configuration
#-------------------------------------------------------------------------------
Initial commit of python boiler-plate.
2020-04-27 06:50:23 +08:00
Misc fixes to enable building/testing on manylinux2014 images. * Since the manylinux images do not hard-link against python libs (resolving them at runtime), the module must be built without resolving undefined references. * For some reason, builds on this platform are stricter, exposing dependency ordering issues. * The CMake bits to build the extension are still somewhat of a mess. I have better versions both upstream and in IREE and will be reconciling. For now, don't look too closely.
2020-08-05 08:10:14 +08:00
set(NPCOMP_PYTHON_BINDINGS_VERSION_LOCKED 1 CACHE BOOL
"Links to specific python libraries, resolving all symbols.")
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
find_package(Python3 COMPONENTS Interpreter Development REQUIRED)
message(STATUS "Found python include dirs: ${Python3_INCLUDE_DIRS}")
message(STATUS "Found python libraries: ${Python3_LIBRARIES}")
Initial commit of python boiler-plate.
2020-04-27 06:50:23 +08:00
Add pytorch interface to ATen Dialect (#30) This patch adds a pytorch interface to npcomp. This interface is modeled after pytorch_xla and exposes the MLIR-based flow as a virtual device (similar to a gpu device or the xla backend). Usage is intended to be something like: dev = torch_mlir.mlir_device() t0 = torch.randn((4,4), device=dev) t1 = torch.randn((4,4), device=dev) t2 = t0 + t1 t2_mlir = torch_mlir.get_mlir( t2 ) t2_cpu = t2.to('cpu') In this case t2_cpu would contain the result of the computation, and t2_mlir contains the mlir description of the computation. Note that this also properly returns backward paths synthesized by pytorch. There are several parts of this: 1) A tensor type (implemented by tensor.* and tensor_impl.*) 2) The device modeling (aten_mlir_bridge.*, aten_mlir_device.*, aten_mlir_type*) 3) a temporary IR (implemented by ir.cpp) There is also a reference lowering directly from the ATen dialect to C function calls consisting of two parts: 1) The driver that uses the IR to generate MLIR, run Passes and compile the result using mlir::ExecutionEngine (implemented by jit.cpp and mlir_gen.cpp) 2) A runtime library implemented by lib/aten_ops.cpp. Most of the operations are implemented by callbacks into the torch C++ libraries. Some aspects of this are known to be less than optimal, in particular: 1) There's some function definitions that don't live in the file corresponding to their declaration. 2) More aspects of this (e.g. the IR) seem like they should be automatically generated. 3) It's unclear to me how much of the 'IR' is actually necessary, or whether MLIR could be created on the fly. Note that this code is licensed in a way similar to pytorch, with the intention that eventually (when npcomp reaches some maturity) it should be pushed there. (see frontends/pytorch/LICENSE) The code is also structured much closer to the pytorch coding style than the LLVM coding style.
2020-08-22 02:22:47 +08:00
#-------------------------------------------------------------------------------
# Pytorch Configuration
#-------------------------------------------------------------------------------
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
NpcompFindPyTorch(${NPCOMP_ENABLE_PYTORCH})
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
#-------------------------------------------------------------------------------
# Pybind11 Configuration
#-------------------------------------------------------------------------------
Bump llvm-project to f4f8a67aaf13bc66a2b7d55561b14a3724a5e0de. * Incorporates source fixes. * Uses upstream pybind11 detection logic. * Patches CI. * This may break the CI, which will need to be fixed manually in a followup.
2020-11-23 05:01:15 +08:00
npcomp_detect_pybind11_install()
find_package(pybind11 2.6 CONFIG REQUIRED)
set(pybind11_INCLUDE_DIR ${pybind11_INCLUDE_DIR})
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
message(STATUS "Found pybind11 v${pybind11_VERSION}: ${pybind11_INCLUDE_DIR}")
message(STATUS "Python prefix = '${PYTHON_MODULE_PREFIX}', "
"suffix = '${PYTHON_MODULE_SUFFIX}', "
"extension = '${PYTHON_MODULE_EXTENSION}")
Add pytorch interface to ATen Dialect (#30) This patch adds a pytorch interface to npcomp. This interface is modeled after pytorch_xla and exposes the MLIR-based flow as a virtual device (similar to a gpu device or the xla backend). Usage is intended to be something like: dev = torch_mlir.mlir_device() t0 = torch.randn((4,4), device=dev) t1 = torch.randn((4,4), device=dev) t2 = t0 + t1 t2_mlir = torch_mlir.get_mlir( t2 ) t2_cpu = t2.to('cpu') In this case t2_cpu would contain the result of the computation, and t2_mlir contains the mlir description of the computation. Note that this also properly returns backward paths synthesized by pytorch. There are several parts of this: 1) A tensor type (implemented by tensor.* and tensor_impl.*) 2) The device modeling (aten_mlir_bridge.*, aten_mlir_device.*, aten_mlir_type*) 3) a temporary IR (implemented by ir.cpp) There is also a reference lowering directly from the ATen dialect to C function calls consisting of two parts: 1) The driver that uses the IR to generate MLIR, run Passes and compile the result using mlir::ExecutionEngine (implemented by jit.cpp and mlir_gen.cpp) 2) A runtime library implemented by lib/aten_ops.cpp. Most of the operations are implemented by callbacks into the torch C++ libraries. Some aspects of this are known to be less than optimal, in particular: 1) There's some function definitions that don't live in the file corresponding to their declaration. 2) More aspects of this (e.g. the IR) seem like they should be automatically generated. 3) It's unclear to me how much of the 'IR' is actually necessary, or whether MLIR could be created on the fly. Note that this code is licensed in a way similar to pytorch, with the intention that eventually (when npcomp reaches some maturity) it should be pushed there. (see frontends/pytorch/LICENSE) The code is also structured much closer to the pytorch coding style than the LLVM coding style.
2020-08-22 02:22:47 +08:00
Add initial support for taking a dep on IREE. * This won't work for most people until some upstream changes percolate. * Sequestered it behind a flag and a special configure script (cmake_configure_iree.sh) for now.
2020-06-12 07:40:31 +08:00
#-------------------------------------------------------------------------------
# Directory setup
#-------------------------------------------------------------------------------
set(MLIR_NPCOMP_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(MLIR_NPCOMP_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
Aggregate all lit test targets under check-npcomp.
2020-06-08 05:35:58 +08:00
add_custom_target(check-npcomp)
Enable building using LLVM_EXTERNAL_PROJECTS. (#152) This allows building NPCOMP as an external project of LLVM, similar to how CIRCT can be built: https://github.com/llvm/circt/pull/227. The CMake options to use this build style look like this: ``` -DLLVM_EXTERNAL_PROJECTS=npcomp \ -DLLVM_EXTERNAL_NPCOMP_SOURCE_DIR=/path/to/mlir-npcomp \ ```
2021-01-27 02:43:43 +08:00
add_custom_target(check-npcomp-all)
add_dependencies(check-npcomp-all check-npcomp)
Aggregate all lit test targets under check-npcomp.
2020-06-08 05:35:58 +08:00
Initial commit of python boiler-plate.
2020-04-27 06:50:23 +08:00
add_subdirectory(include/npcomp)
add_subdirectory(lib)
Misc fixes to enable building/testing on manylinux2014 images. * Since the manylinux images do not hard-link against python libs (resolving them at runtime), the module must be built without resolving undefined references. * For some reason, builds on this platform are stricter, exposing dependency ordering issues. * The CMake bits to build the extension are still somewhat of a mess. I have better versions both upstream and in IREE and will be reconciling. For now, don't look too closely.
2020-08-05 08:10:14 +08:00
add_subdirectory(python)
Add npcomp-opt and lit runner.
2020-04-27 08:55:15 +08:00
add_subdirectory(test)
Start reworking towards a shared library build. * Need to have a dag of shared library deps in order to interop across python extensions (as presented in ODM). * Introduced add_npcomp_library and friends to mirror the MLIR setup. * Adds a libNPCOMP.so shared library. * Redirects tools and extensions to link against libNPCOMP.so (instead of static libs). * Moves all libraries to lib/, all binaries to bin/ and all python extensions to python/. The invariant is that the rpaths are setup to have a one level directory structure. * Reworks the _torch_mlir extension to build like the others (still need to come up with a consolidated rule to do this instead of open coded). * Includes an upstream version bump to pick up needed changes. Sizes with dynamic linking (stripped, release, asserts enabled): libNPCOMP.so: 43M (includes much of the underlying LLVM codegen deps) libMLIR.so: 31M _npcomp.so: 1.6M (python extension) _torch_mlir.so: 670K (python extension) npcomp-capi-ir-test: 6.3K npcomp-opt: 351K npcomp-run-mlir: 461K mnist-playground: 530K Still more can be done to normalize and optimize but this gets us structurally to the starting point.
2020-10-09 09:29:59 +08:00
# Tools needs to come late to ensure that NPCOMP_ALL_LIBS is populated.
# Generally things after this point may depend on NPCOMP_ALL_LIBS or libNPCOMP.so.
add_subdirectory(tools)
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(${TORCH_FOUND})
add_subdirectory(frontends/pytorch)
else()
message("Skipping pytorch frontend, because PyTorch not found!")
endif()