maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/lib/ExecutionEngine/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

50 lines
1.2 KiB
CMake
Raw Normal View History

[mlir] NFC - Move runner utils from mlir-cpu-runner to ExecutionEngine Runner utils are useful beyond just CPU and hiding them within the test directory makes it unnecessarily harder to reuse in other projects.
2020-02-27 22:51:15 +08:00
set(LLVM_OPTIONAL_SOURCES
[mlir] NFC - Split out RunnerUtils that don't require a C++ runtime Summary: This revision split out a new CRunnerUtils library that supports MLIR execution on targets without a C++ runtime. Differential Revision: https://reviews.llvm.org/D75257
2020-02-28 02:45:43 +08:00
CRunnerUtils.cpp
[mlir] NFC - Move runner utils from mlir-cpu-runner to ExecutionEngine Runner utils are useful beyond just CPU and hiding them within the test directory makes it unnecessarily harder to reuse in other projects.
2020-02-27 22:51:15 +08:00
ExecutionEngine.cpp
RunnerUtils.cpp
OptUtils.cpp
)
Add build files and update README. * Add initial version of build files; * Update README with instructions to download and build MLIR from github; -- PiperOrigin-RevId: 241102092
2019-03-30 13:10:12 +08:00
llvm_map_components_to_libnames(outlibs "nativecodegen" "IPO")
[MLIR] Add support for libMLIR.so Putting this up mainly for discussion on how this should be done. I am interested in MLIR from the Julia side and we currently have a strong preference to dynamically linking against the LLVM shared library, and would like to have a MLIR shared library. This patch adds a new cmake function add_mlir_library() which accumulates a list of targets to be compiled into libMLIR.so. Note that not all libraries make sense to be compiled into libMLIR.so. In particular, we want to avoid libraries which primarily exist to support certain tools (such as mlir-opt and mlir-cpu-runner). Note that the resulting libMLIR.so depends on LLVM, but does not contain any LLVM components. As a result, it is necessary to link with libLLVM.so to avoid linkage errors. So, libMLIR.so requires LLVM_BUILD_LLVM_DYLIB=on FYI, Currently it appears that LLVM_LINK_LLVM_DYLIB is broken because mlir-tblgen is linked against libLLVM.so and and independent LLVM components. Previous version of this patch broke depencies on TableGen targets. This appears to be because it compiled all libraries to OBJECT libraries (probably because cmake is generating different target names). Avoiding object libraries results in correct dependencies. (updated by Stephen Neuendorffer) Differential Revision: https://reviews.llvm.org/D73130
2020-02-09 11:27:54 +08:00
add_mlir_library(MLIRExecutionEngine
Add build files and update README. * Add initial version of build files; * Update README with instructions to download and build MLIR from github; -- PiperOrigin-RevId: 241102092
2019-03-30 13:10:12 +08:00
ExecutionEngine.cpp
OptUtils.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/ExecutionEngine
Revert "[MLIR] Move from using target_link_libraries to LINK_LIBS for llvm libraries." This reverts commit 7a6c68977114b91097d693e9cfcb636631f61f91. This breaks the build with cmake 3.13.4, but succeeds with cmake 3.15.3
2020-03-01 03:51:04 +08:00
)
target_link_libraries(MLIRExecutionEngine
[MLIR] Ensure that target_link_libraries() always has a keyword. CMake allows calling target_link_libraries() without a keyword, but this usage is not preferred when also called with a keyword, and has surprising behavior. This patch explicitly specifies a keyword when using target_link_libraries(). Differential Revision: https://reviews.llvm.org/D75725
2020-03-06 03:49:42 +08:00
PUBLIC
Reduce reliance on custom grown Jit implementation - NFC This CL makes use of the standard LLVM LLJIT and removes the need for a custom JIT implementation within MLIR. To achieve this, one needs to clone (i.e. serde) the produced llvm::Module into a new LLVMContext. This is currently necessary because the llvm::LLVMContext is owned by the LLVMDialect, somewhat deep in the call hierarchy. In the future we should remove the reliance of serding the llvm::Module by allowing the injection of an LLVMContext from the top-level. Unfortunately this will require deeper API changes and impact multiple places. It is therefore left for future work. PiperOrigin-RevId: 264737459
2019-08-22 09:15:39 +08:00
MLIRLLVMIR
MLIRTargetLLVMIR
LLVMBitReader
LLVMBitWriter
LLVMExecutionEngine
[MLIR] Fix lib/ExecutionEngine for BUILD_SHARED_LIBS=on
2020-02-11 00:55:27 +08:00
LLVMObject
Reduce reliance on custom grown Jit implementation - NFC This CL makes use of the standard LLVM LLJIT and removes the need for a custom JIT implementation within MLIR. To achieve this, one needs to clone (i.e. serde) the produced llvm::Module into a new LLVMContext. This is currently necessary because the llvm::LLVMContext is owned by the LLVMDialect, somewhat deep in the call hierarchy. In the future we should remove the reliance of serding the llvm::Module by allowing the injection of an LLVMContext from the top-level. Unfortunately this will require deeper API changes and impact multiple places. It is therefore left for future work. PiperOrigin-RevId: 264737459
2019-08-22 09:15:39 +08:00
LLVMOrcJIT
[MLIR] Fixes for shared library dependencies. Summary: This patch is a step towards enabling BUILD_SHARED_LIBS=on, which builds most libraries as DLLs instead of statically linked libraries. The main effect of this is that incremental build times are greatly reduced, since usually only one library need be relinked in response to isolated code changes. The bulk of this patch is fixing incorrect usage of cmake, where library dependencies are listed under add_dependencies rather than under target_link_libraries or under the LINK_LIBS tag. Correct usage should be like this: add_dependencies(MLIRfoo MLIRfooIncGen) target_link_libraries(MLIRfoo MLIRlib1 MLIRlib2) A separate issue is that in cmake, dependencies between static libraries are automatically included in dependencies. In the above example, if MLIBlib1 depends on MLIRlib2, then it is sufficient to have only MLIRlib1 in the target_link_libraries. When compiling with shared libraries, it is necessary to have both MLIRlib1 and MLIRlib2 specified if MLIRfoo uses symbols from both. Reviewers: mravishankar, antiagainst, nicolasvasilache, vchuravy, inouehrs, mehdi_amini, jdoerfert Reviewed By: nicolasvasilache, mehdi_amini Subscribers: Joonsoo, merge_guards_bot, jholewinski, mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, csigg, arpith-jacob, mgester, lucyrfox, herhut, aartbik, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73653
2020-01-01 09:23:01 +08:00
LLVMJITLink
Reduce reliance on custom grown Jit implementation - NFC This CL makes use of the standard LLVM LLJIT and removes the need for a custom JIT implementation within MLIR. To achieve this, one needs to clone (i.e. serde) the produced llvm::Module into a new LLVMContext. This is currently necessary because the llvm::LLVMContext is owned by the LLVMDialect, somewhat deep in the call hierarchy. In the future we should remove the reliance of serding the llvm::Module by allowing the injection of an LLVMContext from the top-level. Unfortunately this will require deeper API changes and impact multiple places. It is therefore left for future work. PiperOrigin-RevId: 264737459
2019-08-22 09:15:39 +08:00
LLVMSupport
[MLIR] Fixes for shared library dependencies. Summary: This patch is a step towards enabling BUILD_SHARED_LIBS=on, which builds most libraries as DLLs instead of statically linked libraries. The main effect of this is that incremental build times are greatly reduced, since usually only one library need be relinked in response to isolated code changes. The bulk of this patch is fixing incorrect usage of cmake, where library dependencies are listed under add_dependencies rather than under target_link_libraries or under the LINK_LIBS tag. Correct usage should be like this: add_dependencies(MLIRfoo MLIRfooIncGen) target_link_libraries(MLIRfoo MLIRlib1 MLIRlib2) A separate issue is that in cmake, dependencies between static libraries are automatically included in dependencies. In the above example, if MLIBlib1 depends on MLIRlib2, then it is sufficient to have only MLIRlib1 in the target_link_libraries. When compiling with shared libraries, it is necessary to have both MLIRlib1 and MLIRlib2 specified if MLIRfoo uses symbols from both. Reviewers: mravishankar, antiagainst, nicolasvasilache, vchuravy, inouehrs, mehdi_amini, jdoerfert Reviewed By: nicolasvasilache, mehdi_amini Subscribers: Joonsoo, merge_guards_bot, jholewinski, mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, csigg, arpith-jacob, mgester, lucyrfox, herhut, aartbik, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73653
2020-01-01 09:23:01 +08:00
LLVMAnalysis
LLVMAggressiveInstCombine
LLVMInstCombine
LLVMMC
LLVMScalarOpts
LLVMTarget
LLVMVectorize
Reduce reliance on custom grown Jit implementation - NFC This CL makes use of the standard LLVM LLJIT and removes the need for a custom JIT implementation within MLIR. To achieve this, one needs to clone (i.e. serde) the produced llvm::Module into a new LLVMContext. This is currently necessary because the llvm::LLVMContext is owned by the LLVMDialect, somewhat deep in the call hierarchy. In the future we should remove the reliance of serding the llvm::Module by allowing the injection of an LLVMContext from the top-level. Unfortunately this will require deeper API changes and impact multiple places. It is therefore left for future work. PiperOrigin-RevId: 264737459
2019-08-22 09:15:39 +08:00
LLVMTransformUtils
Revert "[MLIR] Move from using target_link_libraries to LINK_LIBS for llvm libraries." This reverts commit 7a6c68977114b91097d693e9cfcb636631f61f91. This breaks the build with cmake 3.13.4, but succeeds with cmake 3.15.3
2020-03-01 03:51:04 +08:00
${outlibs})
[mlir] NFC - Move runner utils from mlir-cpu-runner to ExecutionEngine Runner utils are useful beyond just CPU and hiding them within the test directory makes it unnecessarily harder to reuse in other projects.
2020-02-27 22:51:15 +08:00
[mlir] NFC - Split out RunnerUtils that don't require a C++ runtime Summary: This revision split out a new CRunnerUtils library that supports MLIR execution on targets without a C++ runtime. Differential Revision: https://reviews.llvm.org/D75257
2020-02-28 02:45:43 +08:00
add_llvm_library(mlir_c_runner_utils SHARED CRunnerUtils.cpp)
[mlir][CRunnerUtils] Enable compilation with C++11 toolchain on microcontroller platforms. Summary: The C runner utils API was still not vanilla enough for certain use cases on embedded ARM SDKs, this enables such cases. Adding people more widely for historical Windows related build issues. Differential Revision: https://reviews.llvm.org/D76031
2020-03-12 22:07:16 +08:00
set_property(TARGET mlir_c_runner_utils PROPERTY CXX_STANDARD 11)
[mlir] Hotfix - Fix Windows build This revision adds a static `mlir_c_runner_utils_static` library for the sole purpose of being linked into `mlir_runner_utils` on Windows. It was previously reported that: ``` `add_llvm_library(mlir_c_runner_utils SHARED CRunnerUtils.cpp)` produces *only* a dll on windows, the linking of mlir_runner_utils fails because target_link_libraries is looking for a .lib file as opposed to a .dll file. I think this may be a case where either we need to use LINK_LIBS or explicitly build a static lib as well, but I haven't tried either yet. ```
2020-03-03 11:47:16 +08:00
add_llvm_library(mlir_c_runner_utils_static CRunnerUtils.cpp)
[mlir][CRunnerUtils] Enable compilation with C++11 toolchain on microcontroller platforms. Summary: The C runner utils API was still not vanilla enough for certain use cases on embedded ARM SDKs, this enables such cases. Adding people more widely for historical Windows related build issues. Differential Revision: https://reviews.llvm.org/D76031
2020-03-12 22:07:16 +08:00
set_property(TARGET mlir_c_runner_utils_static PROPERTY CXX_STANDARD 11)
[mlir] NFC - Split out RunnerUtils that don't require a C++ runtime Summary: This revision split out a new CRunnerUtils library that supports MLIR execution on targets without a C++ runtime. Differential Revision: https://reviews.llvm.org/D75257
2020-02-28 02:45:43 +08:00
target_compile_definitions(mlir_c_runner_utils PRIVATE mlir_c_runner_utils_EXPORTS)
[mlir] Hotfix - Rename MLIRRuntimeUtils to mlir_runtime_utils
2020-02-28 01:58:41 +08:00
add_llvm_library(mlir_runner_utils SHARED RunnerUtils.cpp)
[mlir] NFC - Split out RunnerUtils that don't require a C++ runtime Summary: This revision split out a new CRunnerUtils library that supports MLIR execution on targets without a C++ runtime. Differential Revision: https://reviews.llvm.org/D75257
2020-02-28 02:45:43 +08:00
target_link_libraries(mlir_runner_utils
[MLIR] Ensure that target_link_libraries() always has a keyword. CMake allows calling target_link_libraries() without a keyword, but this usage is not preferred when also called with a keyword, and has surprising behavior. This patch explicitly specifies a keyword when using target_link_libraries(). Differential Revision: https://reviews.llvm.org/D75725
2020-03-06 03:49:42 +08:00
PUBLIC
[mlir] Hotfix - Fix Windows build This revision adds a static `mlir_c_runner_utils_static` library for the sole purpose of being linked into `mlir_runner_utils` on Windows. It was previously reported that: ``` `add_llvm_library(mlir_c_runner_utils SHARED CRunnerUtils.cpp)` produces *only* a dll on windows, the linking of mlir_runner_utils fails because target_link_libraries is looking for a .lib file as opposed to a .dll file. I think this may be a case where either we need to use LINK_LIBS or explicitly build a static lib as well, but I haven't tried either yet. ```
2020-03-03 11:47:16 +08:00
mlir_c_runner_utils_static
[mlir] NFC - Split out RunnerUtils that don't require a C++ runtime Summary: This revision split out a new CRunnerUtils library that supports MLIR execution on targets without a C++ runtime. Differential Revision: https://reviews.llvm.org/D75257
2020-02-28 02:45:43 +08:00
)
[mlir] Hotfix - Rename MLIRRuntimeUtils to mlir_runtime_utils
2020-02-28 01:58:41 +08:00
target_compile_definitions(mlir_runner_utils PRIVATE mlir_runner_utils_EXPORTS)