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

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

36 lines
1.3 KiB
CMake
Raw Normal View History

[mlir] Add MLIR-C dylib. Per discussion on discord and various feature requests across bindings (Haskell and Rust bindings authors have asked me directly), we should be building a link-ready MLIR-C dylib which exports the C API and can be used without linking to anything else. This patch: * Adds a new MLIR-C aggregate shared library (libMLIR-C.so), which is similar in name and function to libLLVM-C.so. * It is guarded by the new CMake option MLIR_BUILD_MLIR_C_DYLIB, which has a similar purpose/name to the LLVM_BUILD_LLVM_C_DYLIB option. * On all platforms, this will work with both static, BUILD_SHARED_LIBS, and libMLIR builds, if supported: * In static builds: libMLIR-C.so will export the CAPI symbols and statically link all dependencies into itself. * In BUILD_SHARED_LIBS: libMLIR-C.so will export the CAPI symbols and have dynamic dependencies on implementation shared libraries. * In libMLIR.so mode: same as static. libMLIR.so was not finished for actual linking use within the project. An eventual relayering so that libMLIR-C.so depends on libMLIR.so is possible but requires first re-engineering the latter to use the aggregate facility. * On Linux, exported symbols are filtered to only the CAPI. On others (MacOS, Windows), all symbols are exported. A CMake status is printed unless if global visibility is hidden indicating that this has not yet been implemented. The library should still work, but it will be larger and more likely to conflict until fixed. Someone should look at lifting the corresponding support from libLLVM-C.so and adapting. Or, for special uses, just build with `-DCMAKE_CXX_VISIBILITY_PRESET=hidden -DCMAKE_C_VISIBILITY_PRESET=hidden`. * Includes fixes to execution engine symbol export macros to enable default visibility. Without this, the advice to use hidden visibility would have resulted in test failures and unusable execution engine support libraries. Differential Revision: https://reviews.llvm.org/D113731
2021-11-12 13:18:16 +08:00
# For upstream, we accumulate all libraries into the MLIR_CAPI_LIBRARIES
# property via a custom wrapper function. This is then used to create an
# aggregate below.
set_property(GLOBAL APPEND PROPERTY MLIR_CAPI_LIBRARIES)
function(add_mlir_upstream_c_api_library name)
add_mlir_public_c_api_library(${name} ${ARGN})
set_property(GLOBAL APPEND PROPERTY MLIR_CAPI_LIBRARIES ${name})
endfunction()
[mlir] Improve debug flag management in Python bindings Expose the debug flag as a readable and assignable property of a dedicated class instead of a write-only function. Actually test the fact of setting the flag. Move test to a dedicated file, it has zero relation to context_managers.py where it was added. Arguably, it should be promoted from mlir.ir to mlir module, but we are not re-exporting the latter and this functionality is purposefully hidden so can stay in IR for now. Drop unnecessary export code. Refactor C API and put Debug into a separate library, fix it to actually set the flag to the given value. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D100757
2021-04-19 19:37:01 +08:00
add_subdirectory(Debug)
Add C bindings for mlir::ExecutionEngine This adds minimalistic bindings for the execution engine, allowing to invoke the JIT from the C API. This is still quite early and experimental and shouldn't be considered stable in any way. Differential Revision: https://reviews.llvm.org/D96651
2021-02-14 03:23:06 +08:00
add_subdirectory(Dialect)
add_subdirectory(Conversion)
add_subdirectory(ExecutionEngine)
[mlir] support interfaces in Python bindings Introduce the initial support for operation interfaces in C API and Python bindings. Interfaces are a key component of MLIR's extensibility and should be available in bindings to make use of full potential of MLIR. This initial implementation exposes InferTypeOpInterface all the way to the Python bindings since it can be later used to simplify the operation construction methods by inferring their return types instead of requiring the user to do so. The general infrastructure for binding interfaces is defined and InferTypeOpInterface can be used as an example for binding other interfaces. Reviewed By: gysit Differential Revision: https://reviews.llvm.org/D111656
2021-10-14 23:18:28 +08:00
add_subdirectory(Interfaces)
[mlir] Initial version of C APIs Introduce an initial version of C API for MLIR core IR components: Value, Type, Attribute, Operation, Region, Block, Location. These APIs allow for both inspection and creation of the IR in the generic form and intended for wrapping in high-level library- and language-specific constructs. At this point, there is no stability guarantee provided for the API. Reviewed By: stellaraccident, lattner Differential Revision: https://reviews.llvm.org/D83310
2020-08-05 20:36:16 +08:00
add_subdirectory(IR)
add_subdirectory(Registration)
Add a basic C API for the MLIR PassManager as well as a basic TableGen backend for creating passes This is exposing the basic functionalities (create, nest, addPass, run) of the PassManager through the C API in the new header: `include/mlir-c/Pass.h`. In order to exercise it in the unit-test, a basic TableGen backend is also provided to generate a simple C wrapper around the pass constructor. It is used to expose the libTransforms passes to the C API. Reviewed By: stellaraccident, ftynse Differential Revision: https://reviews.llvm.org/D90667
2020-11-04 05:38:34 +08:00
add_subdirectory(Transforms)
[mlir] Add MLIR-C dylib. Per discussion on discord and various feature requests across bindings (Haskell and Rust bindings authors have asked me directly), we should be building a link-ready MLIR-C dylib which exports the C API and can be used without linking to anything else. This patch: * Adds a new MLIR-C aggregate shared library (libMLIR-C.so), which is similar in name and function to libLLVM-C.so. * It is guarded by the new CMake option MLIR_BUILD_MLIR_C_DYLIB, which has a similar purpose/name to the LLVM_BUILD_LLVM_C_DYLIB option. * On all platforms, this will work with both static, BUILD_SHARED_LIBS, and libMLIR builds, if supported: * In static builds: libMLIR-C.so will export the CAPI symbols and statically link all dependencies into itself. * In BUILD_SHARED_LIBS: libMLIR-C.so will export the CAPI symbols and have dynamic dependencies on implementation shared libraries. * In libMLIR.so mode: same as static. libMLIR.so was not finished for actual linking use within the project. An eventual relayering so that libMLIR-C.so depends on libMLIR.so is possible but requires first re-engineering the latter to use the aggregate facility. * On Linux, exported symbols are filtered to only the CAPI. On others (MacOS, Windows), all symbols are exported. A CMake status is printed unless if global visibility is hidden indicating that this has not yet been implemented. The library should still work, but it will be larger and more likely to conflict until fixed. Someone should look at lifting the corresponding support from libLLVM-C.so and adapting. Or, for special uses, just build with `-DCMAKE_CXX_VISIBILITY_PRESET=hidden -DCMAKE_C_VISIBILITY_PRESET=hidden`. * Includes fixes to execution engine symbol export macros to enable default visibility. Without this, the advice to use hidden visibility would have resulted in test failures and unusable execution engine support libraries. Differential Revision: https://reviews.llvm.org/D113731
2021-11-12 13:18:16 +08:00
# Build the optional CAPI dylib.
if(MLIR_BUILD_MLIR_C_DYLIB)
message(STATUS "Building MLIR-C dylib")
get_property(_capi_libraries GLOBAL PROPERTY MLIR_CAPI_LIBRARIES)
add_mlir_aggregate(MLIR-C
SHARED
EMBED_LIBS
${_capi_libraries}
)
if(CMAKE_SYSTEM_NAME STREQUAL "Linux")
target_link_options(MLIR-C PRIVATE "-Wl,-exclude-libs,ALL")
else()
if(NOT CMAKE_C_VISIBILITY_PRESET STREQUAL "hidden" OR NOT CMAKE_CXX_VISIBILITY_PRESET STREQUAL "hidden")
message(STATUS "MLIR-C on this platform exports all symbols. Recommend building with CMAKE_(C|CXX)_VISIBILITY_PRESET=hidden or implement filtering support.")
endif()
endif()
endif()