2019-04-30 03:11:58 +08:00
|
|
|
set(LLVM_OPTIONAL_SOURCES
|
|
|
|
|
null.cpp
|
|
|
|
|
)
|
|
|
|
|
|
2020-02-27 03:50:03 +08:00
|
|
|
get_property(dialect_libs GLOBAL PROPERTY MLIR_DIALECT_LIBS)
|
2020-02-27 08:31:14 +08:00
|
|
|
get_property(conversion_libs GLOBAL PROPERTY MLIR_CONVERSION_LIBS)
|
2020-05-05 03:41:43 +08:00
|
|
|
set(LLVM_LINK_COMPONENTS
|
|
|
|
|
Core
|
|
|
|
|
Support
|
|
|
|
|
AsmParser
|
|
|
|
|
)
|
|
|
|
|
|
2020-05-19 00:44:26 +08:00
|
|
|
if(MLIR_INCLUDE_TESTS)
|
|
|
|
|
set(test_libs
|
2022-03-02 06:53:41 +08:00
|
|
|
MLIRTestFuncToLLVM
|
2020-05-19 00:44:26 +08:00
|
|
|
MLIRAffineTransformsTestPasses
|
2021-05-15 01:27:57 +08:00
|
|
|
MLIRDLTITestPasses
|
2022-02-27 06:49:54 +08:00
|
|
|
MLIRFuncTestPasses
|
2021-05-15 01:27:57 +08:00
|
|
|
MLIRGPUTestPasses
|
|
|
|
|
MLIRLinalgTestPasses
|
|
|
|
|
MLIRMathTestPasses
|
2022-01-27 06:18:21 +08:00
|
|
|
MLIRMemRefTestPasses
|
2021-05-15 01:27:57 +08:00
|
|
|
MLIRSCFTestPasses
|
2020-11-30 03:15:30 +08:00
|
|
|
MLIRShapeTestPasses
|
2020-05-19 00:44:26 +08:00
|
|
|
MLIRSPIRVTestPasses
|
2022-02-17 00:26:47 +08:00
|
|
|
MLIRTensorTestPasses
|
2021-02-10 06:11:00 +08:00
|
|
|
MLIRTestAnalysis
|
2020-05-19 00:44:26 +08:00
|
|
|
MLIRTestDialect
|
|
|
|
|
MLIRTestIR
|
|
|
|
|
MLIRTestPass
|
2022-04-20 13:46:34 +08:00
|
|
|
MLIRTestPDLL
|
2020-07-11 08:46:55 +08:00
|
|
|
MLIRTestReducer
|
[mlir][PDL] Add support for PDL bytecode and expose PDL support to OwningRewritePatternList
PDL patterns are now supported via a new `PDLPatternModule` class. This class contains a ModuleOp with the pdl::PatternOp operations representing the patterns, as well as a collection of registered C++ functions for native constraints/creations/rewrites/etc. that may be invoked via the pdl patterns. Instances of this class are added to an OwningRewritePatternList in the same fashion as C++ RewritePatterns, i.e. via the `insert` method.
The PDL bytecode is an in-memory representation of the PDL interpreter dialect that can be efficiently interpreted/executed. The representation of the bytecode boils down to a code array(for opcodes/memory locations/etc) and a memory buffer(for storing attributes/operations/values/any other data necessary). The bytecode operations are effectively a 1-1 mapping to the PDLInterp dialect operations, with a few exceptions in cases where the in-memory representation of the bytecode can be more efficient than the MLIR representation. For example, a generic `AreEqual` bytecode op can be used to represent AreEqualOp, CheckAttributeOp, and CheckTypeOp.
The execution of the bytecode is split into two phases: matching and rewriting. When matching, all of the matched patterns are collected to avoid the overhead of re-running parts of the matcher. These matched patterns are then considered alongside the native C++ patterns, which rewrite immediately in-place via `RewritePattern::matchAndRewrite`, for the given root operation. When a PDL pattern is matched and has the highest benefit, it is passed back to the bytecode to execute its rewriter.
Differential Revision: https://reviews.llvm.org/D89107
2020-12-02 06:30:18 +08:00
|
|
|
MLIRTestRewrite
|
[mlir] Introduce Transform dialect
This dialect provides operations that can be used to control transformation of
the IR using a different portion of the IR. It refers to the IR being
transformed as payload IR, and to the IR guiding the transformation as
transform IR.
The main use case for this dialect is orchestrating fine-grain transformations
on individual operations or sets thereof. For example, it may involve finding
loop-like operations with specific properties (e.g., large size) in the payload
IR, applying loop tiling to those and only those operations, and then applying
loop unrolling to the inner loops produced by the previous transformations. As
such, it is not intended as a replacement for the pass infrastructure, nor for
the pattern rewriting infrastructure. In the most common case, the transform IR
will be processed and applied to payload IR by a pass. Transformations
expressed by the transform dialect may be implemented using the pattern
infrastructure or any other relevant MLIR component.
This dialect is designed to be extensible, that is, clients of this dialect are
allowed to inject additional operations into this dialect using the newly
introduced in this patch `TransformDialectExtension` mechanism. This allows the
dialect to avoid a dependency on the implementation of the transformation as
well as to avoid introducing dialect-specific transform dialects.
See https://discourse.llvm.org/t/rfc-interfaces-and-dialects-for-precise-ir-transformation-control/60927.
Reviewed By: nicolasvasilache, Mogball, rriddle
Differential Revision: https://reviews.llvm.org/D123135
2022-04-14 19:16:48 +08:00
|
|
|
MLIRTestTransformDialect
|
2020-05-19 00:44:26 +08:00
|
|
|
MLIRTestTransforms
|
2022-02-17 00:26:47 +08:00
|
|
|
MLIRVectorTestPasses
|
2020-05-19 00:44:26 +08:00
|
|
|
)
|
|
|
|
|
endif()
|
|
|
|
|
|
2020-02-12 17:03:40 +08:00
|
|
|
set(LIBS
|
2020-02-27 03:50:03 +08:00
|
|
|
${dialect_libs}
|
2020-02-27 08:31:14 +08:00
|
|
|
${conversion_libs}
|
2020-05-19 00:44:26 +08:00
|
|
|
${test_libs}
|
2022-01-15 15:34:09 +08:00
|
|
|
MLIRAffineAnalysis
|
2019-11-22 07:19:52 +08:00
|
|
|
MLIRAnalysis
|
[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
|
|
|
MLIRDialect
|
2020-02-12 16:41:40 +08:00
|
|
|
MLIROptLib
|
2019-03-30 13:10:12 +08:00
|
|
|
MLIRParser
|
|
|
|
|
MLIRPass
|
|
|
|
|
MLIRTransforms
|
[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
|
|
|
MLIRTransformUtils
|
2019-03-30 13:10:12 +08:00
|
|
|
MLIRSupport
|
2020-02-06 01:06:36 +08:00
|
|
|
MLIRIR
|
2020-03-07 07:46:51 +08:00
|
|
|
)
|
|
|
|
|
|
2020-05-05 03:41:43 +08:00
|
|
|
# Exclude from libMLIR.so because this has static options intended for
|
|
|
|
|
# opt-like tools only.
|
|
|
|
|
add_mlir_library(MLIRMlirOptMain
|
2020-03-07 07:46:51 +08:00
|
|
|
mlir-opt.cpp
|
2020-05-05 03:41:43 +08:00
|
|
|
|
|
|
|
|
EXCLUDE_FROM_LIBMLIR
|
|
|
|
|
|
2020-05-06 03:26:48 +08:00
|
|
|
LINK_LIBS PUBLIC
|
2020-03-07 07:46:51 +08:00
|
|
|
${LIBS}
|
2020-05-05 03:41:43 +08:00
|
|
|
)
|
2020-02-06 01:06:36 +08:00
|
|
|
|
2020-10-05 06:17:34 +08:00
|
|
|
add_llvm_tool(mlir-opt
|
2020-05-05 03:41:43 +08:00
|
|
|
mlir-opt.cpp
|
2020-02-12 18:06:50 +08:00
|
|
|
|
2020-05-05 03:41:43 +08:00
|
|
|
DEPENDS
|
|
|
|
|
${LIBS}
|
|
|
|
|
)
|
|
|
|
|
target_link_libraries(mlir-opt PRIVATE ${LIBS})
|
2019-04-02 01:17:45 +08:00
|
|
|
llvm_update_compile_flags(mlir-opt)
|
2020-05-05 03:41:43 +08:00
|
|
|
|
2020-05-17 13:46:57 +08:00
|
|
|
mlir_check_all_link_libraries(mlir-opt)
|