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

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

66 lines
1.2 KiB
CMake
Raw Normal View History

[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(MLIRTargetLLVMIRModuleTranslation
[mlir] Add support for basic location translation to LLVM. Summary: This revision adds basic support for emitting line table information when exporting to LLVMIR. We don't yet have a story for supporting all of the LLVM debug metadata, so this revision stubs some features(like subprograms) to enable emitting line tables. Differential Revision: https://reviews.llvm.org/D73934
2020-02-06 09:10:55 +08:00
LLVMIR/DebugTranslation.cpp
Add transformation of the NVVM dialect to an LLVM module. Only handles the generation of intrinsics out of NVVM index ops for now. -- PiperOrigin-RevId: 245933152
2019-04-30 21:08:21 +08:00
LLVMIR/ModuleTranslation.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Target/LLVMIR
DEPENDS
intrinsics_gen
)
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(MLIRTargetLLVMIRModuleTranslation
[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] 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
MLIRLLVMIR
[mlir] LLVM dialect: move ensureDistinctSuccessors out of std->LLVM conversion MLIR supports terminators that have the same successor block with different block operands, which cannot be expressed in the LLVM's phi-notation as the block identifier is used to tell apart the predecessors. This limitation can be worked around by branching to a new block instead, with this new block unconditionally branching to the original successor and forwarding the argument. Until now, this transformation was performed during the conversion from the Standard to the LLVM dialect. This does not scale well to multiple dialects targeting the LLVM dialect as all of them would have to be aware of this limitation and perform the preparatory transformation. Instead, do it as a separate pass and run it immediately before the translation. Differential Revision: https://reviews.llvm.org/D75619
2020-03-17 22:06:41 +08:00
MLIRLLVMIRTransforms
[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
LLVMCore
LLVMIRReader
LLVMSupport
LLVMTransformUtils
MLIRTranslation
)
add_mlir_library(MLIRTargetLLVMIR
[llvm] Add initial import of LLVM modules to mlir-translate This adds an importer from LLVM IR or bitcode to the LLVM dialect. The importer is registered with mlir-translate. Known issues exposed by this patch but not yet fixed: * Globals' initializers are attributes, which makes it impossible to represent a ConstantExpr. This will be fixed in a followup. * icmp returns i32 rather than i1. * select and a couple of other instructions aren't implemented. * llvm.cond_br takes its successors in a weird order. The testing here is known to be non-exhaustive. I'd appreciate feedback on where this functionality should live. It looks like the translator *from MLIR to LLVM* lives in Target/, but the SPIR-V deserializer lives in Dialect/ which is why I've put this here too. PiperOrigin-RevId: 278711683
2019-11-06 06:41:08 +08:00
LLVMIR/ConvertFromLLVMIR.cpp
Add transformation of the NVVM dialect to an LLVM module. Only handles the generation of intrinsics out of NVVM index ops for now. -- PiperOrigin-RevId: 245933152
2019-04-30 21:08:21 +08:00
LLVMIR/ConvertToLLVMIR.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Target/LLVMIR
)
[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
target_link_libraries(MLIRTargetLLVMIR
PUBLIC
[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
MLIRTargetLLVMIRModuleTranslation
)
add_mlir_library(MLIRTargetNVVMIR
Add transformation of the NVVM dialect to an LLVM module. Only handles the generation of intrinsics out of NVVM index ops for now. -- PiperOrigin-RevId: 245933152
2019-04-30 21:08:21 +08:00
LLVMIR/ConvertToNVVMIR.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Target/LLVMIR
DEPENDS
intrinsics_gen
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(MLIRTargetNVVMIR
[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
NVVM target: emit nvvm.annotations for kernel functions PTX backend in LLVM expects additional module-level metadata `!nvvm.annotations` that lists functions that can be used as GPU kernels. Generate this metadata based on the `gpu.kernel` attribute attached to functions. This attribute is added automatically by the kernel outlining pass in the GPU dialect lowering flow. PiperOrigin-RevId: 254957345
2019-06-25 21:30:32 +08:00
MLIRGPU
MLIRIR
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
MLIRLLVMIR
NVVM target: emit nvvm.annotations for kernel functions PTX backend in LLVM expects additional module-level metadata `!nvvm.annotations` that lists functions that can be used as GPU kernels. Generate this metadata based on the `gpu.kernel` attribute attached to functions. This attribute is added automatically by the kernel outlining pass in the GPU dialect lowering flow. PiperOrigin-RevId: 254957345
2019-06-25 21:30:32 +08:00
MLIRNVVMIR
MLIRTargetLLVMIRModuleTranslation
)
[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(MLIRTargetROCDLIR
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
LLVMIR/ConvertToROCDLIR.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Target/LLVMIR
DEPENDS
intrinsics_gen
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(MLIRTargetROCDLIR
[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
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
MLIRGPU
MLIRIR
Use llvm.func to define functions with wrapped LLVM IR function type This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
2019-10-10 16:33:33 +08:00
MLIRLLVMIR
[ROCm] Adding ROCDL Dialect. This commit introduces the ROCDL Dialect (i.e. the ROCDL ops + the code to lower those ROCDL ops to LLWM intrinsics/functions). Think of ROCDL Dialect as analogous to the NVVM Dialect, but for AMD GPUs. This patch contains just the essentials needed to get a simple example up and running. We expect to make further additions to the ROCDL Dialect. This is the first of 3 commits, the follow-up will be: * add a pass that lowers GPU Dialect to ROCDL Dialect * add a "mlir-rocm-runner" utility Closes tensorflow/mlir#146 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/146 from deven-amd:deven-rocdl-dialect e78e8005c75a78912631116c78dc844fcc4b0de9 PiperOrigin-RevId: 271511259
2019-09-27 14:49:51 +08:00
MLIRROCDLIR
MLIRTargetLLVMIRModuleTranslation
)