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

71 lines
1.2 KiB
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
[mlir] Add a new BranchOpInterface to allow for opaquely interfacing with branching terminator operations. This interface contains the necessary components to provide the same builtin behavior that terminators have. This will be used in future revisions to remove many of the hardcoded constraints placed on successors and successor operands. The interface initially contains three methods: ```c++ // Return a set of values corresponding to the operands for successor 'index', or None if the operands do not correspond to materialized values. Optional<OperandRange> getSuccessorOperands(unsigned index); // Return true if this terminator can have it's successor operands erased. bool canEraseSuccessorOperand(); // Erase the operand of a successor. This is only valid to call if 'canEraseSuccessorOperand' returns true. void eraseSuccessorOperand(unsigned succIdx, unsigned opIdx); ``` Differential Revision: https://reviews.llvm.org/D75314
2020-03-06 04:40:23 +08:00
ControlFlowInterfaces.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
Dominance.cpp
Add InferTypeOpTrait & enable generating its member function definition Use OpInterfaces to add an interface for ops defining a return type function. This change does not use this trait in any meaningful way, I'll use it in a follow up to generalize and unify some of the op type traits/constraints. Also, currently the infer type function can only be manually specified in C++, that should rather be the fallback in future. PiperOrigin-RevId: 271883746
2019-09-30 08:28:29 +08:00
InferTypeOpInterface.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
Verifier.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] Fixes for BUILD_SHARED_LIBS=on Differential Revision: https://reviews.llvm.org/D75308
2020-02-28 06:53:12 +08:00
add_mlir_library(MLIRControlFlowAnalysis
ControlFlowInterfaces.cpp
ADDITIONAL_HEADER_DIRS
${MLIR_MAIN_INCLUDE_DIR}/mlir/Analysis
DEPENDS
MLIRControlFlowInterfacesIncGen
)
target_link_libraries(MLIRControlFlowAnalysis
PUBLIC
MLIRIR
)
[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
InferTypeOpInterface.cpp
Liveness.cpp
SliceAnalysis.cpp
Dominance.cpp
Verifier.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] Move from add_dependencies() to DEPENDS add_llvm_library and add_llvm_executable may need to create new targets with appropriate dependencies. As a result, it is not sufficient in some configurations (namely LLVM_BUILD_LLVM_DYLIB=on) to only call add_dependencies(). Instead, the explicit TableGen dependencies must be passed to add_llvm_library() or add_llvm_executable() using the DEPENDS keyword. Differential Revision: https://reviews.llvm.org/D74930
2020-02-21 02:48:51 +08:00
DEPENDS
Revert "[MLIR] Move from add_dependencies() to DEPENDS" This reverts commit 31e07d716a083b85df226c31f6ba72bc477f58fc.
2020-03-01 03:50:31 +08:00
MLIRCallOpInterfacesIncGen
MLIRTypeInferOpInterfaceIncGen
)
[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] 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
target_link_libraries(MLIRAnalysis
PUBLIC
MLIRAffineOps
MLIRLoopOps
)
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] Move from add_dependencies() to DEPENDS add_llvm_library and add_llvm_executable may need to create new targets with appropriate dependencies. As a result, it is not sufficient in some configurations (namely LLVM_BUILD_LLVM_DYLIB=on) to only call add_dependencies(). Instead, the explicit TableGen dependencies must be passed to add_llvm_library() or add_llvm_executable() using the DEPENDS keyword. Differential Revision: https://reviews.llvm.org/D74930
2020-02-21 02:48:51 +08:00
DEPENDS
Revert "[MLIR] Move from add_dependencies() to DEPENDS" This reverts commit 31e07d716a083b85df226c31f6ba72bc477f58fc.
2020-03-01 03:50:31 +08:00
MLIRCallOpInterfacesIncGen
MLIRTypeInferOpInterfaceIncGen
)
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] 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
target_link_libraries(MLIRLoopAnalysis
PUBLIC
MLIRAffineOps
MLIRLoopOps)