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.

137 lines
2.2 KiB
CMake
Raw Normal View History

[mlir][spirv] NFC: split deserialization into multiple source files This avoids large source files and gives a better structure. It also allows leveraging compilation parallelism. Reviewed By: mravishankar Differential Revision: https://reviews.llvm.org/D94360
2021-01-13 00:11:45 +08:00
add_subdirectory(SPIRV)
[MLIR] add cmake abstraction for translation libraries Differential Revision: https://reviews.llvm.org/D77926
2020-04-11 07:58:39 +08:00
add_mlir_translation_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
[mlir] translate types between MLIR LLVM dialect and LLVM IR With new LLVM dialect type modeling, the dialect types no longer wrap LLVM IR types. Therefore, they need to be translated to and from LLVM IR during export and import. Introduce the relevant functionality for translating types. It is currently exercised by an ad-hoc type translation roundtripping test that will be subsumed by the actual translation test when the type system transition is complete. Depends On D84339 Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D85019
2020-08-04 17:37:25 +08:00
LLVMIR/TypeTranslation.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
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Target/LLVMIR
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
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
DEPENDS
intrinsics_gen
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
LINK_COMPONENTS
Core
FrontendOpenMP
TransformUtils
LINK_LIBS 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] Fix shared libs build The following change causes the shared libraries build (BUILD_SHARED_LIBS=On) to fail: * https://reviews.llvm.org/D88351 This patch will fix that. Differential Revision: https://reviews.llvm.org/D88484
2020-09-29 21:20:35 +08:00
MLIROpenMP
[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
MLIRTranslation
)
[MLIR] add cmake abstraction for translation libraries Differential Revision: https://reviews.llvm.org/D77926
2020-04-11 07:58:39 +08:00
add_mlir_translation_library(MLIRTargetAVX512
[mlir][AVX512] Start a primitive AVX512 dialect The Vector Dialect [document](https://mlir.llvm.org/docs/Dialects/Vector/) discusses the vector abstractions that MLIR supports and the various tradeoffs involved. One of the layer that is missing in OSS atm is the Hardware Vector Ops (HWV) level. This revision proposes an AVX512-specific to add a new Dialect/Targets/AVX512 Dialect that would directly target AVX512-specific intrinsics. Atm, we rely too much on LLVM’s peephole optimizer to do a good job from small insertelement/extractelement/shufflevector. In the future, when possible, generic abstractions such as VP intrinsics should be preferred. The revision will allow trading off HW-specific vs generic abstractions in MLIR. Differential Revision: https://reviews.llvm.org/D75987
2020-03-21 02:05:49 +08:00
LLVMIR/LLVMAVX512Intr.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Target/LLVMIR
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
[mlir][AVX512] Start a primitive AVX512 dialect The Vector Dialect [document](https://mlir.llvm.org/docs/Dialects/Vector/) discusses the vector abstractions that MLIR supports and the various tradeoffs involved. One of the layer that is missing in OSS atm is the Hardware Vector Ops (HWV) level. This revision proposes an AVX512-specific to add a new Dialect/Targets/AVX512 Dialect that would directly target AVX512-specific intrinsics. Atm, we rely too much on LLVM’s peephole optimizer to do a good job from small insertelement/extractelement/shufflevector. In the future, when possible, generic abstractions such as VP intrinsics should be preferred. The revision will allow trading off HW-specific vs generic abstractions in MLIR. Differential Revision: https://reviews.llvm.org/D75987
2020-03-21 02:05:49 +08:00
DEPENDS
MLIRLLVMAVX512ConversionsIncGen
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
LINK_COMPONENTS
Core
LINK_LIBS PUBLIC
[mlir][AVX512] Start a primitive AVX512 dialect The Vector Dialect [document](https://mlir.llvm.org/docs/Dialects/Vector/) discusses the vector abstractions that MLIR supports and the various tradeoffs involved. One of the layer that is missing in OSS atm is the Hardware Vector Ops (HWV) level. This revision proposes an AVX512-specific to add a new Dialect/Targets/AVX512 Dialect that would directly target AVX512-specific intrinsics. Atm, we rely too much on LLVM’s peephole optimizer to do a good job from small insertelement/extractelement/shufflevector. In the future, when possible, generic abstractions such as VP intrinsics should be preferred. The revision will allow trading off HW-specific vs generic abstractions in MLIR. Differential Revision: https://reviews.llvm.org/D75987
2020-03-21 02:05:49 +08:00
MLIRIR
MLIRLLVMAVX512
MLIRLLVMIR
MLIRTargetLLVMIRModuleTranslation
)
[MLIR] add cmake abstraction for translation libraries Differential Revision: https://reviews.llvm.org/D77926
2020-04-11 07:58:39 +08:00
add_mlir_translation_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] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
LINK_COMPONENTS
Core
IRReader
LINK_LIBS 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
)
[mlir][ArmNeon][RFC] Add a Neon dialect This revision starts an Arm-specific ArmNeon dialect discussed in the [discourse RFC thread](https://llvm.discourse.group/t/rfc-vector-dialects-neon-and-sve/2284). Differential Revision: https://reviews.llvm.org/D92171
2020-12-11 20:53:49 +08:00
add_mlir_translation_library(MLIRTargetArmNeon
LLVMIR/LLVMArmNeonIntr.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Target/LLVMIR
DEPENDS
MLIRLLVMArmNeonConversionsIncGen
LINK_COMPONENTS
Core
LINK_LIBS PUBLIC
MLIRIR
MLIRLLVMArmNeon
MLIRLLVMIR
MLIRTargetLLVMIRModuleTranslation
)
[mlir][ArmSVE][RFC] Add an ArmSVE dialect This revision starts an Arm-specific ArmSVE dialect discussed in the discourse RFC thread: https://llvm.discourse.group/t/rfc-vector-dialects-neon-and-sve/2284 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D92172
2020-12-15 05:30:53 +08:00
add_mlir_translation_library(MLIRTargetArmSVE
LLVMIR/LLVMArmSVEIntr.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Target/LLVMIR
DEPENDS
MLIRLLVMArmSVEConversionsIncGen
LINK_COMPONENTS
Core
LINK_LIBS PUBLIC
MLIRIR
MLIRLLVMArmSVE
MLIRLLVMIR
MLIRTargetLLVMIRModuleTranslation
)
[MLIR] add cmake abstraction for translation libraries Differential Revision: https://reviews.llvm.org/D77926
2020-04-11 07:58:39 +08:00
add_mlir_translation_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
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
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
DEPENDS
intrinsics_gen
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
LINK_COMPONENTS
Core
LINK_LIBS 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
[MLIR] add cmake abstraction for translation libraries Differential Revision: https://reviews.llvm.org/D77926
2020-04-11 07:58:39 +08:00
add_mlir_translation_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
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
[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
DEPENDS
intrinsics_gen
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
LINK_COMPONENTS
Core
LINK_LIBS 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
)