[all-commits] [llvm/llvm-project] c5a671: [mlir] Add basic support for attributes in ODS-gen...

[ftynse via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: c5a6712f8cee1bfbb5d730531943558645853c0b
      https://github.com/llvm/llvm-project/commit/c5a6712f8cee1bfbb5d730531943558645853c0b
  Author: Alex Zinenko <zinenko at google.com>
  Date:   2020-11-17 (Tue, 17 Nov 2020)

  Changed paths:
    M mlir/CMakeLists.txt
    M mlir/cmake/modules/AddMLIRPythonExtension.cmake
    M mlir/include/mlir/Dialect/StandardOps/IR/CMakeLists.txt
    A mlir/lib/Bindings/Python/Attributes.td
    M mlir/lib/Bindings/Python/CMakeLists.txt
    M mlir/lib/Bindings/Python/IRModules.cpp
    A mlir/lib/Bindings/Python/StandardOps.td
    M mlir/lib/TableGen/Operator.cpp
    M mlir/test/mlir-tblgen/op-python-bindings.td
    M mlir/tools/mlir-tblgen/OpPythonBindingGen.cpp

  Log Message:
  -----------
  [mlir] Add basic support for attributes in ODS-generated Python bindings

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