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

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

51 lines
826 B
CMake
Raw Normal View History

[MLIR] Break cyclic dependencies with MLIRAnalysis Summary: MLIRAnalysis depended on MLIRVectorOps MLIRVectorOps depended on MLIRAnalysis for Loop information. Both of these can be solved by factoring out libraries related to loop analysis into their own library. The new MLIRLoopAnalysis might be better off with the Loop Dialect in the future. Reviewers: nicolasvasilache, rriddle!, mehdi_amini Reviewed By: mehdi_amini Subscribers: Joonsoo, vchuravy, merge_guards_bot, mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73655
2020-01-30 03:20:19 +08:00
set(LLVM_OPTIONAL_SOURCES
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
AffineAnalysis.cpp
AffineStructures.cpp
Add interfaces for call-like/callable operations. These two operation interfaces will be used in a followup to support building a callgraph: * CallOpInterface - Operations providing this interface are call-like, and have a "call" target. A call target may be a symbol reference, via SymbolRefAttr, or a SSA value. * CallableOpInterface - Operations providing this interfaces define destinations to call-like operations, e.g. FuncOp. These operations may define any number of callable regions. PiperOrigin-RevId: 270723300
2019-09-24 02:36:37 +08:00
CallGraph.cpp
Roll-forward initial liveness analysis including test cases. Fix the usage of the map size when appending to the map with []. PiperOrigin-RevId: 284985916
2019-12-12 00:01:56 +08:00
Liveness.cpp
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
LoopAnalysis.cpp
NestedMatcher.cpp
SliceAnalysis.cpp
Utils.cpp
[MLIR] Break cyclic dependencies with MLIRAnalysis Summary: MLIRAnalysis depended on MLIRVectorOps MLIRVectorOps depended on MLIRAnalysis for Loop information. Both of these can be solved by factoring out libraries related to loop analysis into their own library. The new MLIRLoopAnalysis might be better off with the Loop Dialect in the future. Reviewers: nicolasvasilache, rriddle!, mehdi_amini Reviewed By: mehdi_amini Subscribers: Joonsoo, vchuravy, merge_guards_bot, mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73655
2020-01-30 03:20:19 +08:00
)
[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(MLIRAnalysis
[MLIR] Break cyclic dependencies with MLIRAnalysis Summary: MLIRAnalysis depended on MLIRVectorOps MLIRVectorOps depended on MLIRAnalysis for Loop information. Both of these can be solved by factoring out libraries related to loop analysis into their own library. The new MLIRLoopAnalysis might be better off with the Loop Dialect in the future. Reviewers: nicolasvasilache, rriddle!, mehdi_amini Reviewed By: mehdi_amini Subscribers: Joonsoo, vchuravy, merge_guards_bot, mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73655
2020-01-30 03:20:19 +08:00
CallGraph.cpp
Liveness.cpp
SliceAnalysis.cpp
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
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Analysis
[MLIR] add dependencies for all tablegen targets on 'mlir-headers' In cmake, dependencies on generated files require some sophistication in the build system. At build time, files are parsed to determine which headers they depend on and these dependencies are injected into the build system. This works well with ninja, but has some constraints with the makefile generator. According to the cmake documentation, this only works reliably within the same directory. This patch expands the usage of mlir-headers to include all generated headers and adds an mlir-generic-headers target which triggers generation of dialect-independent headers. These targets are used to express dependencies on generated headers. This is mostly handled in AddMLIR.cmake and only a few CMakeLists.txt files need to change. Differential Revision: https://reviews.llvm.org/D79242
2020-04-25 07:42:07 +08:00
[MLIR] Fix dependencies for Analysis libraries cmake does not truly support dependencies on automatically generated files which are not in the same directory as the targets which depend on them. It works with ninja, but doesn't work with make This patch adds an explicit dependence so that all dialects are built before the analysis libraries. Differential Revision: https://reviews.llvm.org/D79805
2020-05-13 04:37:31 +08:00
DEPENDS
mlir-headers
[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
[MLIR] Complete refactoring of Affine dialect into sub-libraries. There were some unused CMakeFiles for Affine/IR and Affine/EDSC. This change builds separate MLIRAffineOps and MLIRAffineEDSC libraries using those CMakeFiles. This combination replaces the old MLIRAffine library. Differential Revision: https://reviews.llvm.org/D78317
2020-04-17 02:11:13 +08:00
MLIRAffineOps
[mlir][NFC] Move the operation interfaces out of Analysis/ and into a new Interfaces/ directory. The interfaces themselves aren't really analyses, they may be used by analyses though. Having them in Analysis can also create cyclic dependencies if an analysis depends on a specific dialect, that also provides one of the interfaces. Differential Revision: https://reviews.llvm.org/D75867
2020-03-11 03:20:24 +08:00
MLIRCallInterfaces
MLIRControlFlowInterfaces
MLIRInferTypeOpInterface
[mlir] NFC: Rename LoopOps dialect to SCF (Structured Control Flow) This dialect contains various structured control flow operaitons, not only loops, reflect this in the name. Drop the Ops suffix for consistency with other dialects. Note that this only moves the files and changes the C++ namespace from 'loop' to 'scf'. The visible IR prefix remains the same and will be updated separately. The conversions will also be updated separately. Differential Revision: https://reviews.llvm.org/D79578
2020-05-11 21:00:48 +08:00
MLIRSCF
[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
)
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
[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(MLIRLoopAnalysis
[MLIR] Break cyclic dependencies with MLIRAnalysis Summary: MLIRAnalysis depended on MLIRVectorOps MLIRVectorOps depended on MLIRAnalysis for Loop information. Both of these can be solved by factoring out libraries related to loop analysis into their own library. The new MLIRLoopAnalysis might be better off with the Loop Dialect in the future. Reviewers: nicolasvasilache, rriddle!, mehdi_amini Reviewed By: mehdi_amini Subscribers: Joonsoo, vchuravy, merge_guards_bot, mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73655
2020-01-30 03:20:19 +08:00
AffineAnalysis.cpp
AffineStructures.cpp
LoopAnalysis.cpp
NestedMatcher.cpp
Utils.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Analysis
[MLIR] add dependencies for all tablegen targets on 'mlir-headers' In cmake, dependencies on generated files require some sophistication in the build system. At build time, files are parsed to determine which headers they depend on and these dependencies are injected into the build system. This works well with ninja, but has some constraints with the makefile generator. According to the cmake documentation, this only works reliably within the same directory. This patch expands the usage of mlir-headers to include all generated headers and adds an mlir-generic-headers target which triggers generation of dialect-independent headers. These targets are used to express dependencies on generated headers. This is mostly handled in AddMLIR.cmake and only a few CMakeLists.txt files need to change. Differential Revision: https://reviews.llvm.org/D79242
2020-04-25 07:42:07 +08:00
[MLIR] Fix dependencies for Analysis libraries cmake does not truly support dependencies on automatically generated files which are not in the same directory as the targets which depend on them. It works with ninja, but doesn't work with make This patch adds an explicit dependence so that all dialects are built before the analysis libraries. Differential Revision: https://reviews.llvm.org/D79805
2020-05-13 04:37:31 +08:00
DEPENDS
mlir-headers
[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
[MLIR] Complete refactoring of Affine dialect into sub-libraries. There were some unused CMakeFiles for Affine/IR and Affine/EDSC. This change builds separate MLIRAffineOps and MLIRAffineEDSC libraries using those CMakeFiles. This combination replaces the old MLIRAffine library. Differential Revision: https://reviews.llvm.org/D78317
2020-04-17 02:11:13 +08:00
MLIRAffineOps
[mlir][NFC] Move the operation interfaces out of Analysis/ and into a new Interfaces/ directory. The interfaces themselves aren't really analyses, they may be used by analyses though. Having them in Analysis can also create cyclic dependencies if an analysis depends on a specific dialect, that also provides one of the interfaces. Differential Revision: https://reviews.llvm.org/D75867
2020-03-11 03:20:24 +08:00
MLIRCallInterfaces
MLIRControlFlowInterfaces
MLIRInferTypeOpInterface
[mlir] NFC: Rename LoopOps dialect to SCF (Structured Control Flow) This dialect contains various structured control flow operaitons, not only loops, reflect this in the name. Drop the Ops suffix for consistency with other dialects. Note that this only moves the files and changes the C++ namespace from 'loop' to 'scf'. The visible IR prefix remains the same and will be updated separately. The conversions will also be updated separately. Differential Revision: https://reviews.llvm.org/D79578
2020-05-11 21:00:48 +08:00
MLIRSCF
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClang This reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
2020-05-05 03:41:43 +08:00
)