[mlir][capi] Unbreak Interfaces CAPI after 2387fadea3No idea why check-mlir doesn't build this.
[mlir] Refactor AbstractOperation and OperationNameThe current implementation is quite clunky; OperationName stores either an Identifieror an AbstractOperation that corresponds to an operation. Th
[mlir] Refactor AbstractOperation and OperationNameThe current implementation is quite clunky; OperationName stores either an Identifieror an AbstractOperation that corresponds to an operation. This has several problems:* OperationNames created before and after an operation are registered are different* Accessing the identifier name/dialect/etc. from an OperationName are overly branchy - they need to dyn_cast a PointerUnion to check the stateThis commit refactors this such that we create a single information struct for everyoperation name, even operations that aren't registered yet. When an OperationName iscreated for an unregistered operation, we only populate the name field. When theoperation is registered, we populate the remaining fields. With this we now have twonew classes: OperationName and RegisteredOperationName. These both point to thesame underlying operation information struct, but only RegisteredOperationName canassume that the operation is actually registered. This leads to a much cleaner API, andwe can also move some AbstractOperation functionality directly to OperationName.Differential Revision: https://reviews.llvm.org/D114049
show more ...
[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
[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
[mlir] support interfaces in Python bindingsIntroduce the initial support for operation interfaces in C API and Pythonbindings. Interfaces are a key component of MLIR's extensibility and should be
[mlir] support interfaces in Python bindingsIntroduce the initial support for operation interfaces in C API and Pythonbindings. Interfaces are a key component of MLIR's extensibility and should beavailable in bindings to make use of full potential of MLIR.This initial implementation exposes InferTypeOpInterface all the way to thePython bindings since it can be later used to simplify the operationconstruction methods by inferring their return types instead of requiring theuser to do so. The general infrastructure for binding interfaces is defined andInferTypeOpInterface can be used as an example for binding other interfaces.Reviewed By: gysitDifferential Revision: https://reviews.llvm.org/D111656