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

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

24 lines
367 B
CMake
Raw Normal View History

[mlir] Rename conversions involving ex-Loop dialect to mention SCF The following Conversions are affected: LoopToStandard -> SCFToStandard, LoopsToGPU -> SCFToGPU, VectorToLoops -> VectorToSCF. Full file paths are affected. Additionally, drop the 'Convert' prefix from filenames living under lib/Conversion where applicable. API names and CLI options for pass testing are also renamed when applicable. In particular, LoopsToGPU contains several passes that apply to different kinds of loops (`for` or `parallel`), for which the original names are preserved. Differential Revision: https://reviews.llvm.org/D79940
2020-05-14 20:41:35 +08:00
add_mlir_conversion_library(MLIRSCFToGPU
SCFToGPU.cpp
SCFToGPUPass.cpp
[MLIR] Remove redundant library dependencies In cmake, it is redundant to have a target list under target_link_libraries() and add_dependency(). This patch removes the redundant dependency from add_dependency(). Differential Revision: https://reviews.llvm.org/D74929
2020-02-20 14:56:38 +08:00
ADDITIONAL_HEADER_DIRS
[mlir] Rename conversions involving ex-Loop dialect to mention SCF The following Conversions are affected: LoopToStandard -> SCFToStandard, LoopsToGPU -> SCFToGPU, VectorToLoops -> VectorToSCF. Full file paths are affected. Additionally, drop the 'Convert' prefix from filenames living under lib/Conversion where applicable. API names and CLI options for pass testing are also renamed when applicable. In particular, LoopsToGPU contains several passes that apply to different kinds of loops (`for` or `parallel`), for which the original names are preserved. Differential Revision: https://reviews.llvm.org/D79940
2020-05-14 20:41:35 +08:00
${MLIR_MAIN_INCLUDE_DIR}/mlir/Conversion/SCFToGPU
[mlir][Pass] Move the registration of conversion passes to tablegen This removes the need to statically register conversion passes, and also puts all of the conversions within one centralized file. Differential Revision: https://reviews.llvm.org/D76658
2020-04-01 16:49:43 +08:00
DEPENDS
MLIRConversionPassIncGen
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
LINK_LIBS PUBLIC
Remove `Ops` suffix from dialect library names Dialects include more than just ops, so this suffix is outdated. Follows discussion in https://llvm.discourse.group/t/rfc-canonical-file-paths-to-dialects/621 Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D88530
2020-10-01 08:47:25 +08:00
MLIRAffine
[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
MLIRAffineToStandard
[mlir] Add ComplexDialect to SCF->GPU pass.
2021-01-21 04:11:49 +08:00
MLIRComplex
Extend AffineToGPU to support Linalg loops Extend the utility that converts affine loop nests to support other types of loops by abstracting away common behavior through templates. This also slightly simplifies the existing Affine to GPU conversion by always passing in the loop step as an additional kernel argument even though it is a known constant. If it is used, it will be propagated into the loop body by the existing canonicalization pattern and can be further constant-folded, otherwise it will be dropped by canonicalization. This prepares for the common loop abstraction that will be used for converting to GPU kernels, which is conceptually close to Linalg loops, while maintaining the existing conversion operational. PiperOrigin-RevId: 257172216
2019-07-09 20:26:18 +08:00
MLIRGPU
MLIRIR
Remove `Ops` suffix from dialect library names Dialects include more than just ops, so this suffix is outdated. Follows discussion in https://llvm.discourse.group/t/rfc-canonical-file-paths-to-dialects/621 Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D88530
2020-10-01 08:47:25 +08:00
MLIRLinalg
[MLIR] Create memref dialect and move dialect-specific ops from std. Create the memref dialect and move dialect-specific ops from std dialect to this dialect. Moved ops: AllocOp -> MemRef_AllocOp AllocaOp -> MemRef_AllocaOp AssumeAlignmentOp -> MemRef_AssumeAlignmentOp DeallocOp -> MemRef_DeallocOp DimOp -> MemRef_DimOp MemRefCastOp -> MemRef_CastOp MemRefReinterpretCastOp -> MemRef_ReinterpretCastOp GetGlobalMemRefOp -> MemRef_GetGlobalOp GlobalMemRefOp -> MemRef_GlobalOp LoadOp -> MemRef_LoadOp PrefetchOp -> MemRef_PrefetchOp ReshapeOp -> MemRef_ReshapeOp StoreOp -> MemRef_StoreOp SubViewOp -> MemRef_SubViewOp TransposeOp -> MemRef_TransposeOp TensorLoadOp -> MemRef_TensorLoadOp TensorStoreOp -> MemRef_TensorStoreOp TensorToMemRefOp -> MemRef_BufferCastOp ViewOp -> MemRef_ViewOp The roadmap to split the memref dialect from std is discussed here: https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667 Differential Revision: https://reviews.llvm.org/D98041
2021-02-10 20:53:11 +08:00
MLIRMemRef
Extend AffineToGPU to support Linalg loops Extend the utility that converts affine loop nests to support other types of loops by abstracting away common behavior through templates. This also slightly simplifies the existing Affine to GPU conversion by always passing in the loop step as an additional kernel argument even though it is a known constant. If it is used, it will be propagated into the loop body by the existing canonicalization pattern and can be further constant-folded, otherwise it will be dropped by canonicalization. This prepares for the common loop abstraction that will be used for converting to GPU kernels, which is conceptually close to Linalg loops, while maintaining the existing conversion operational. PiperOrigin-RevId: 257172216
2019-07-09 20:26:18 +08:00
MLIRPass
Remove `Ops` suffix from dialect library names Dialects include more than just ops, so this suffix is outdated. Follows discussion in https://llvm.discourse.group/t/rfc-canonical-file-paths-to-dialects/621 Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D88530
2020-10-01 08:47:25 +08:00
MLIRStandard
Extend AffineToGPU to support Linalg loops Extend the utility that converts affine loop nests to support other types of loops by abstracting away common behavior through templates. This also slightly simplifies the existing Affine to GPU conversion by always passing in the loop step as an additional kernel argument even though it is a known constant. If it is used, it will be propagated into the loop body by the existing canonicalization pattern and can be further constant-folded, otherwise it will be dropped by canonicalization. This prepares for the common loop abstraction that will be used for converting to GPU kernels, which is conceptually close to Linalg loops, while maintaining the existing conversion operational. PiperOrigin-RevId: 257172216
2019-07-09 20:26:18 +08:00
MLIRSupport
MLIRTransforms
[MLIR] Remove redundant library dependencies In cmake, it is redundant to have a target list under target_link_libraries() and add_dependency(). This patch removes the redundant dependency from add_dependency(). Differential Revision: https://reviews.llvm.org/D74929
2020-02-20 14:56:38 +08:00
)