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

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

73 lines
1.3 KiB
CMake
Raw Normal View History

Parsing support for Range, View and Slice operations This CL implements the previously unsupported parsing for Range, View and Slice operations. A pass is introduced to lower to the LLVM. Tests are moved out of C++ land and into mlir/test/Examples. This allows better fitting within standard developer workflows. -- PiperOrigin-RevId: 245796600
2019-04-30 03:11:58 +08:00
set(LLVM_OPTIONAL_SOURCES
null.cpp
)
[MLIR] Refactor handling of dialect libraries Instead of creating extra libraries we don't really need, collect a list of all dialects and use that instead. Differential Revision: https://reviews.llvm.org/D75221
2020-02-27 03:50:03 +08:00
get_property(dialect_libs GLOBAL PROPERTY MLIR_DIALECT_LIBS)
[MLIR] Refactor library handling for conversions. Collect a list of conversion libraries in cmake, so we don't have to list these explicitly in most binaries. Differential Revision: https://reviews.llvm.org/D75222
2020-02-27 08:31:14 +08:00
get_property(conversion_libs GLOBAL PROPERTY MLIR_CONVERSION_LIBS)
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
set(LLVM_LINK_COMPONENTS
Core
Support
AsmParser
)
[MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
if(MLIR_INCLUDE_TESTS)
set(test_libs
[mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they test test/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part of the project. This revision cleans this up, and moves the files within to a directory that reflects what is actually being tested. Differential Revision: https://reviews.llvm.org/D102456
2021-05-15 01:27:57 +08:00
MLIRTestStandardToLLVM
[MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
MLIRAffineTransformsTestPasses
[mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they test test/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part of the project. This revision cleans this up, and moves the files within to a directory that reflects what is actually being tested. Differential Revision: https://reviews.llvm.org/D102456
2021-05-15 01:27:57 +08:00
MLIRDLTITestPasses
MLIRGPUTestPasses
MLIRLinalgTestPasses
MLIRMathTestPasses
MLIRSCFTestPasses
[mlir] Add a shape function library op Op with mapping from ops to corresponding shape functions for those op in the library and mechanism to associate shape functions to functions. The mapping of operand to shape function is kept separate from the shape functions themselves as the operation is associated to the shape function and not vice versa, and one could have a common library of shape functions that can be used in different contexts. Use fully qualified names and require a name for shape fn lib ops for now and an explicit print/parse (based around the generated one & GPU module op ones). This commit reverts d9da4c3e73720badfcac5c0dc63c0285bb690770. Fixes missing headers (don't know how that was working locally). Differential Revision: https://reviews.llvm.org/D91672
2020-11-30 03:15:30 +08:00
MLIRShapeTestPasses
[MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
MLIRSPIRVTestPasses
[mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they test test/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part of the project. This revision cleans this up, and moves the files within to a directory that reflects what is actually being tested. Differential Revision: https://reviews.llvm.org/D102456
2021-05-15 01:27:57 +08:00
MLIRStandardOpsTestPasses
MLIRVectorTestPasses
[mlir] Add initial support for an alias analysis framework in MLIR This revision adds a new `AliasAnalysis` class that represents the main alias analysis interface in MLIR. The purpose of this class is not to hold the aliasing logic itself, but to provide an interface into various different alias analysis implementations. As it evolves this should allow for users to plug in specialized alias analysis implementations for their own needs, and have them immediately usable by other analyses and transformations. This revision also adds an initial simple generic alias, LocalAliasAnalysis, that provides support for performing stateless local alias queries between values. This class is similar in scope to LLVM's BasicAA. Differential Revision: https://reviews.llvm.org/D92343
2021-02-10 06:11:00 +08:00
MLIRTestAnalysis
[MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
MLIRTestDialect
MLIRTestIR
MLIRTestPass
Create TestReducer pass - Create a pass that generates bugs based on trivially defined behavior for the purpose of testing the MLIR Reduce Tool. - Implement the functionality inside the pass to crash mlir-opt in the presence of an operation with the name "crashOp". - Register the pass as a test pass in the mlir-opt tool. Reviewed by: jpienaar Differential Revision: https://reviews.llvm.org/D83422
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] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
MLIRTestTransforms
)
endif()
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
set(LIBS
[MLIR] Refactor handling of dialect libraries Instead of creating extra libraries we don't really need, collect a list of all dialects and use that instead. Differential Revision: https://reviews.llvm.org/D75221
2020-02-27 03:50:03 +08:00
${dialect_libs}
[MLIR] Refactor library handling for conversions. Collect a list of conversion libraries in cmake, so we don't have to list these explicitly in most binaries. Differential Revision: https://reviews.llvm.org/D75222
2020-02-27 08:31:14 +08:00
${conversion_libs}
[MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
${test_libs}
[mlir:Analysis] Move the LoopAnalysis library to Dialect/Affine/Analysis The current state of the top level Analysis/ directory is that it contains two libraries; a generic Analysis library (free from dialect dependencies), and a LoopAnalysis library that contains various analysis utilities that originated from Affine loop transformations. This commit moves the LoopAnalysis to the more appropriate home of `Dialect/Affine/Analysis/`, given the use and intention of the majority of the code within it. After the move, if there are generic utilities that would fit better in the top-level Analysis/ directory, we can move them. Differential Revision: https://reviews.llvm.org/D117351
2022-01-15 15:34:09 +08:00
MLIRAffineAnalysis
Move Linalg Transforms that are actually Conversions - NFC PiperOrigin-RevId: 281844602
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
[mlir] Revise naming of MLIROptMain and MLIRMlirOptLib * Rename CMake target MLIROptMain to MLIROptLib: The target provides the main library * Rename CMake target MLIRMlirOptLib to MLIRMlirOptMain: The target provides the main() entry function At the moment, the Bazel configuration of TenorFlow maps the target MlirOptLib to "lib/Support/MlirOptMain.cpp" and MlirOptMain to "tools/mlir-opt/mlir-opt.cpp". This is the other way around in the CMake configuration. As discussed in the context of the pull request https://github.com/tensorflow/tensorflow/pull/36301, it seems useful to revise the naming in the MLIR repo. Differential Revision: https://reviews.llvm.org/D73778
2020-02-12 16:41:40 +08:00
MLIROptLib
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
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
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
MLIRSupport
[MLIR][GPU] Fix build files for mlir-opt. The recent refactoring of build files broke building with the MIR CUDA integration enabled. This fixes it by adding some additional dependencies to mlir-opt. Differential Revision: https://reviews.llvm.org/D74041
2020-02-06 01:06:36 +08:00
MLIRIR
[MLIR] Link MLIRMlirOptMain with the same libraries as mlir-opt MLIRMlirOptMain seems to need the same libraries as mlir-opt. Differential Revision: https://reviews.llvm.org/D75783
2020-03-07 07:46:51 +08:00
)
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
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
[MLIR] Link MLIRMlirOptMain with the same libraries as mlir-opt MLIRMlirOptMain seems to need the same libraries as mlir-opt. Differential Revision: https://reviews.llvm.org/D75783
2020-03-07 07:46:51 +08:00
mlir-opt.cpp
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
EXCLUDE_FROM_LIBMLIR
[MLIR] mlir-opt needs PUBLIC dependence We see intermittent build errors on the windows buildbot because mlir-opt is including Linalg headers which haven't been built yet. This dependence should be resolved by declaring a PUBLIC dependence on the Linalg library when building MLIROptMain.
2020-05-06 03:26:48 +08:00
LINK_LIBS PUBLIC
[MLIR] Link MLIRMlirOptMain with the same libraries as mlir-opt MLIRMlirOptMain seems to need the same libraries as mlir-opt. Differential Revision: https://reviews.llvm.org/D75783
2020-03-07 07:46:51 +08:00
${LIBS}
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
)
[MLIR][GPU] Fix build files for mlir-opt. The recent refactoring of build files broke building with the MIR CUDA integration enabled. This fixes it by adding some additional dependencies to mlir-opt. Differential Revision: https://reviews.llvm.org/D74041
2020-02-06 01:06:36 +08:00
Revert "[RFC] Factor out repetitive cmake patterns for llvm-style projects" This reverts commit e9b87f43bde8b5f0d8a79c5884fdce639b12e0ca. There are issues with macros generating macros without an obvious simple fix so I'm going to revert this and try something different.
2020-10-05 06:17:34 +08:00
add_llvm_tool(mlir-opt
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
mlir-opt.cpp
Fix MLIR build when the NVPTX target isn't configured Differential Revision: https://reviews.llvm.org/D74472
2020-02-12 18:06:50 +08:00
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
DEPENDS
${LIBS}
)
target_link_libraries(mlir-opt PRIVATE ${LIBS})
Fix MacOS build This is making up for some differences in standard library and linker flags. It also get rid of the requirement to build with RTTI. -- PiperOrigin-RevId: 241348845
2019-04-02 01:17:45 +08:00
llvm_update_compile_flags(mlir-opt)
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
[MLIR][cmake][NFC] Update linkage checker for mlir-opt New CMakeLists.txt for MLIRStandardOpsTransforms was incorrect, but wasn't caught by the check. Differential Revision: https://reviews.llvm.org/D80075
2020-05-17 13:46:57 +08:00
mlir_check_all_link_libraries(mlir-opt)