llvm-project/mlir/lib/ExecutionEngine/CMakeLists.txt

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

135 lines
2.3 KiB
CMake
Raw Normal View History

# Exclude these from libMLIR.so because the JIT infrastructure
# is a big dependency which most don't need.
set(LLVM_OPTIONAL_SOURCES
AsyncRuntime.cpp
CRunnerUtils.cpp
SparseUtils.cpp
ExecutionEngine.cpp
RunnerUtils.cpp
OptUtils.cpp
JitRunner.cpp
)
add_mlir_library(MLIRExecutionEngine
ExecutionEngine.cpp
OptUtils.cpp
EXCLUDE_FROM_LIBMLIR
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/ExecutionEngine
DEPENDS
intrinsics_gen
LINK_COMPONENTS
Core
Coroutines
ExecutionEngine
Object
OrcJIT
JITLink
Analysis
AggressiveInstCombine
InstCombine
MC
ScalarOpts
Target
Vectorize
TransformUtils
nativecodegen
IPO
LINK_LIBS PUBLIC
MLIRLLVMIR
MLIRTargetLLVMIR
)
get_property(dialect_libs GLOBAL PROPERTY MLIR_DIALECT_LIBS)
add_mlir_library(MLIRJitRunner
JitRunner.cpp
EXCLUDE_FROM_LIBMLIR
DEPENDS
intrinsics_gen
LINK_COMPONENTS
Core
OrcJIT
JITLink
LINK_LIBS PUBLIC
${dialect_libs}
MLIRExecutionEngine
MLIRIR
MLIRParser
MLIRStandard
MLIRTargetLLVMIR
MLIRTransforms
MLIRStandardToLLVM
MLIRSupport
)
add_mlir_library(mlir_c_runner_utils
SHARED
CRunnerUtils.cpp
SparseUtils.cpp
EXCLUDE_FROM_LIBMLIR
)
set_property(TARGET mlir_c_runner_utils PROPERTY CXX_STANDARD 11)
[mlir] Link mlir_runner_utils statically into cuda/rocm-runtime-wrappers. The runtime-wrappers depend on LLVMSupport, pulling in static initialization code (e.g. command line arguments). Dynamically loading multiple such libraries results in ODR violoations. So far this has not been an issue, but in D94421, I would like to load both the async-runtime and the cuda-runtime-wrappers as part of a cuda-runner integration test. When doing this, code that asserts that an option category is only registered once fails (note that I've only experienced this in Google's bazel where the async-runtime depends on LLVMSupport, but a similar issue would happen in cmake if more than one runtime-wrapper starts to depend on LLVMSupport). The underlying issue is that we have a mix of static and dynamic linking. If all dependencies were loaded as shared objects (i.e. if LLVMSupport was linked dynamically to the runtime wrappers), each dependency would only get loaded once. However, linking dependencies dynamically would require special attention to paths (one could dynamically load the dependencies first given explicit paths). The simpler approach seems to be to link all dependencies statically into a single shared object. This change basically applies the same logic that we have in the c_runner_utils: we have a shared object target that can be loaded dynamically, and we have a static library target that can be linked to other runtime-wrapper shared object targets. Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D94399
2021-01-11 20:04:09 +08:00
target_compile_definitions(mlir_c_runner_utils PRIVATE mlir_c_runner_utils_EXPORTS)
add_mlir_library(mlir_c_runner_utils_static
CRunnerUtils.cpp
SparseUtils.cpp
EXCLUDE_FROM_LIBMLIR
)
set_property(TARGET mlir_c_runner_utils_static PROPERTY CXX_STANDARD 11)
add_mlir_library(mlir_runner_utils
SHARED
RunnerUtils.cpp
EXCLUDE_FROM_LIBMLIR
LINK_LIBS PUBLIC
mlir_c_runner_utils_static
)
target_compile_definitions(mlir_runner_utils PRIVATE mlir_runner_utils_EXPORTS)
[mlir] Link mlir_runner_utils statically into cuda/rocm-runtime-wrappers. The runtime-wrappers depend on LLVMSupport, pulling in static initialization code (e.g. command line arguments). Dynamically loading multiple such libraries results in ODR violoations. So far this has not been an issue, but in D94421, I would like to load both the async-runtime and the cuda-runtime-wrappers as part of a cuda-runner integration test. When doing this, code that asserts that an option category is only registered once fails (note that I've only experienced this in Google's bazel where the async-runtime depends on LLVMSupport, but a similar issue would happen in cmake if more than one runtime-wrapper starts to depend on LLVMSupport). The underlying issue is that we have a mix of static and dynamic linking. If all dependencies were loaded as shared objects (i.e. if LLVMSupport was linked dynamically to the runtime wrappers), each dependency would only get loaded once. However, linking dependencies dynamically would require special attention to paths (one could dynamically load the dependencies first given explicit paths). The simpler approach seems to be to link all dependencies statically into a single shared object. This change basically applies the same logic that we have in the c_runner_utils: we have a shared object target that can be loaded dynamically, and we have a static library target that can be linked to other runtime-wrapper shared object targets. Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D94399
2021-01-11 20:04:09 +08:00
add_mlir_library(mlir_runner_utils_static
RunnerUtils.cpp
EXCLUDE_FROM_LIBMLIR
LINK_LIBS PUBLIC
mlir_c_runner_utils_static
)
add_mlir_library(mlir_async_runtime
SHARED
AsyncRuntime.cpp
EXCLUDE_FROM_LIBMLIR
LINK_LIBS PUBLIC
mlir_c_runner_utils_static
${LLVM_PTHREAD_LIB}
)
set_property(TARGET mlir_async_runtime PROPERTY CXX_VISIBILITY_PRESET hidden)
target_compile_definitions(mlir_async_runtime PRIVATE mlir_async_runtime_EXPORTS)
[mlir] Link mlir_runner_utils statically into cuda/rocm-runtime-wrappers. The runtime-wrappers depend on LLVMSupport, pulling in static initialization code (e.g. command line arguments). Dynamically loading multiple such libraries results in ODR violoations. So far this has not been an issue, but in D94421, I would like to load both the async-runtime and the cuda-runtime-wrappers as part of a cuda-runner integration test. When doing this, code that asserts that an option category is only registered once fails (note that I've only experienced this in Google's bazel where the async-runtime depends on LLVMSupport, but a similar issue would happen in cmake if more than one runtime-wrapper starts to depend on LLVMSupport). The underlying issue is that we have a mix of static and dynamic linking. If all dependencies were loaded as shared objects (i.e. if LLVMSupport was linked dynamically to the runtime wrappers), each dependency would only get loaded once. However, linking dependencies dynamically would require special attention to paths (one could dynamically load the dependencies first given explicit paths). The simpler approach seems to be to link all dependencies statically into a single shared object. This change basically applies the same logic that we have in the c_runner_utils: we have a shared object target that can be loaded dynamically, and we have a static library target that can be linked to other runtime-wrapper shared object targets. Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D94399
2021-01-11 20:04:09 +08:00
add_mlir_library(mlir_async_runtime_static
AsyncRuntime.cpp
EXCLUDE_FROM_LIBMLIR
LINK_LIBS PUBLIC
mlir_c_runner_utils_static
${LLVM_PTHREAD_LIB}
)