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.

29 lines
537 B
CMake
Raw Normal View History

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")
add_llvm_library(MLIRExecutionEngine
ExecutionEngine.cpp
OptUtils.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/ExecutionEngine
)
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
target_link_libraries(MLIRExecutionEngine
MLIRLLVMIR
MLIRTargetLLVMIR
LLVMBitReader
LLVMBitWriter
LLVMExecutionEngine
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
${outlibs})