forked from OSchip/llvm-project
c5a6712f8c
In ODS, attributes of an operation can be provided as a part of the "arguments" field, together with operands. Such attributes are accepted by the op builder and have accessors generated. Implement similar functionality for ODS-generated op-specific Python bindings: the `__init__` method now accepts arguments together with operands, in the same order as in the ODS `arguments` field; the instance properties are introduced to OpView classes to access the attributes. This initial implementation accepts and returns instances of the corresponding attribute class, and not the underlying values since the mapping scheme of the value types between C++, C and Python is not yet clear. Default-valued attributes are not supported as that would require Python to be able to parse C++ literals. Since attributes in ODS are tightely related to the actual C++ type system, provide a separate Tablegen file with the mapping between ODS storage type for attributes (typically, the underlying C++ attribute class), and the corresponding class name. So far, this might look unnecessary since all names match exactly, but this is not necessarily the cases for non-standard, out-of-tree attributes, which may also be placed in non-default namespaces or Python modules. This also allows out-of-tree users to generate Python bindings without having to modify the bindings generator itself. Storage type was preferred over the Tablegen "def" of the attribute class because ODS essentially encodes attribute _constraints_ rather than classes, e.g. there may be many Tablegen "def"s in the ODS that correspond to the same attribute type with additional constraints The presence of the explicit mapping requires the change in the .td file structure: instead of just calling the bindings generator directly on the main ODS file of the dialect, it becomes necessary to create a new file that includes the main ODS file of the dialect and provides the mapping for attribute types. Arguably, this approach offers better separability of the Python bindings in the build system as the main dialect no longer needs to know that it is being processed by the bindings generator. Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D91542 |
||
|---|---|---|
| .. | ||
| AddMLIR.cmake | ||
| AddMLIRPythonExtension.cmake | ||
| CMakeLists.txt | ||
| MLIRConfig.cmake.in | ||