2020-11-10 00:29:21 +08:00
|
|
|
//===- OpPythonBindingGen.cpp - Generator of Python API for MLIR Ops ------===//
|
|
|
|
//
|
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// OpPythonBindingGen uses ODS specification of MLIR ops to generate Python
|
|
|
|
// binding classes wrapping a generic operation API.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "mlir/TableGen/GenInfo.h"
|
|
|
|
#include "mlir/TableGen/Operator.h"
|
|
|
|
#include "llvm/ADT/StringSet.h"
|
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/FormatVariadic.h"
|
|
|
|
#include "llvm/TableGen/Error.h"
|
|
|
|
#include "llvm/TableGen/Record.h"
|
|
|
|
|
|
|
|
using namespace mlir;
|
|
|
|
using namespace mlir::tblgen;
|
|
|
|
|
|
|
|
/// File header and includes.
|
2021-01-20 05:16:16 +08:00
|
|
|
/// {0} is the dialect namespace.
|
2020-11-10 00:29:21 +08:00
|
|
|
constexpr const char *fileHeader = R"Py(
|
|
|
|
# Autogenerated by mlir-tblgen; don't manually edit.
|
|
|
|
|
2020-12-30 09:43:04 +08:00
|
|
|
from . import _cext as _ods_cext
|
2021-01-20 05:16:16 +08:00
|
|
|
from . import extend_opview_class as _ods_extend_opview_class, segmented_accessor as _ods_segmented_accessor, equally_sized_accessor as _ods_equally_sized_accessor, get_default_loc_context as _ods_get_default_loc_context
|
2020-12-30 09:43:04 +08:00
|
|
|
_ods_ir = _ods_cext.ir
|
2021-01-20 05:16:16 +08:00
|
|
|
|
|
|
|
try:
|
|
|
|
from . import _{0} as _ods_ext_module
|
|
|
|
except ImportError:
|
|
|
|
_ods_ext_module = None
|
|
|
|
|
2020-11-10 00:29:21 +08:00
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for dialect class:
|
|
|
|
/// {0} is the dialect namespace.
|
|
|
|
constexpr const char *dialectClassTemplate = R"Py(
|
2020-12-30 09:43:04 +08:00
|
|
|
@_ods_cext.register_dialect
|
|
|
|
class _Dialect(_ods_ir.Dialect):
|
2020-11-10 00:29:21 +08:00
|
|
|
DIALECT_NAMESPACE = "{0}"
|
|
|
|
pass
|
|
|
|
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for operation class:
|
|
|
|
/// {0} is the Python class name;
|
|
|
|
/// {1} is the operation name.
|
|
|
|
constexpr const char *opClassTemplate = R"Py(
|
2020-12-30 09:43:04 +08:00
|
|
|
@_ods_cext.register_operation(_Dialect)
|
2021-01-20 05:16:16 +08:00
|
|
|
@_ods_extend_opview_class(_ods_ext_module)
|
2020-12-30 09:43:04 +08:00
|
|
|
class {0}(_ods_ir.OpView):
|
2020-11-10 00:29:21 +08:00
|
|
|
OPERATION_NAME = "{1}"
|
|
|
|
)Py";
|
|
|
|
|
2021-01-19 03:27:19 +08:00
|
|
|
/// Template for class level declarations of operand and result
|
|
|
|
/// segment specs.
|
|
|
|
/// {0} is either "OPERAND" or "RESULT"
|
|
|
|
/// {1} is the segment spec
|
|
|
|
/// Each segment spec is either None (default) or an array of integers
|
|
|
|
/// where:
|
|
|
|
/// 1 = single element (expect non sequence operand/result)
|
|
|
|
/// -1 = operand/result is a sequence corresponding to a variadic
|
|
|
|
constexpr const char *opClassSizedSegmentsTemplate = R"Py(
|
|
|
|
_ODS_{0}_SEGMENTS = {1}
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for class level declarations of the _ODS_REGIONS spec:
|
|
|
|
/// {0} is the minimum number of regions
|
|
|
|
/// {1} is the Python bool literal for hasNoVariadicRegions
|
|
|
|
constexpr const char *opClassRegionSpecTemplate = R"Py(
|
|
|
|
_ODS_REGIONS = ({0}, {1})
|
|
|
|
)Py";
|
|
|
|
|
2020-11-10 00:29:21 +08:00
|
|
|
/// Template for single-element accessor:
|
|
|
|
/// {0} is the name of the accessor;
|
|
|
|
/// {1} is either 'operand' or 'result';
|
|
|
|
/// {2} is the position in the element list.
|
|
|
|
constexpr const char *opSingleTemplate = R"Py(
|
|
|
|
@property
|
|
|
|
def {0}(self):
|
|
|
|
return self.operation.{1}s[{2}]
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for single-element accessor after a variable-length group:
|
|
|
|
/// {0} is the name of the accessor;
|
|
|
|
/// {1} is either 'operand' or 'result';
|
|
|
|
/// {2} is the total number of element groups;
|
|
|
|
/// {3} is the position of the current group in the group list.
|
|
|
|
/// This works for both a single variadic group (non-negative length) and an
|
|
|
|
/// single optional element (zero length if the element is absent).
|
|
|
|
constexpr const char *opSingleAfterVariableTemplate = R"Py(
|
|
|
|
@property
|
|
|
|
def {0}(self):
|
2020-12-30 09:43:04 +08:00
|
|
|
_ods_variadic_group_length = len(self.operation.{1}s) - {2} + 1
|
|
|
|
return self.operation.{1}s[{3} + _ods_variadic_group_length - 1]
|
2020-11-10 00:29:21 +08:00
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for an optional element accessor:
|
|
|
|
/// {0} is the name of the accessor;
|
|
|
|
/// {1} is either 'operand' or 'result';
|
|
|
|
/// {2} is the total number of element groups;
|
|
|
|
/// {3} is the position of the current group in the group list.
|
|
|
|
constexpr const char *opOneOptionalTemplate = R"Py(
|
|
|
|
@property
|
|
|
|
def {0}(self);
|
|
|
|
return self.operation.{1}s[{3}] if len(self.operation.{1}s) > {2}
|
|
|
|
else None
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for the variadic group accessor in the single variadic group case:
|
|
|
|
/// {0} is the name of the accessor;
|
|
|
|
/// {1} is either 'operand' or 'result';
|
|
|
|
/// {2} is the total number of element groups;
|
|
|
|
/// {3} is the position of the current group in the group list.
|
|
|
|
constexpr const char *opOneVariadicTemplate = R"Py(
|
|
|
|
@property
|
|
|
|
def {0}(self):
|
2020-12-30 09:43:04 +08:00
|
|
|
_ods_variadic_group_length = len(self.operation.{1}s) - {2} + 1
|
|
|
|
return self.operation.{1}s[{3}:{3} + _ods_variadic_group_length]
|
2020-11-10 00:29:21 +08:00
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// First part of the template for equally-sized variadic group accessor:
|
|
|
|
/// {0} is the name of the accessor;
|
|
|
|
/// {1} is either 'operand' or 'result';
|
|
|
|
/// {2} is the total number of variadic groups;
|
|
|
|
/// {3} is the number of non-variadic groups preceding the current group;
|
|
|
|
/// {3} is the number of variadic groups preceding the current group.
|
|
|
|
constexpr const char *opVariadicEqualPrefixTemplate = R"Py(
|
|
|
|
@property
|
|
|
|
def {0}(self):
|
2020-12-30 09:43:04 +08:00
|
|
|
start, pg = _ods_equally_sized_accessor(operation.{1}s, {2}, {3}, {4}))Py";
|
2020-11-10 00:29:21 +08:00
|
|
|
|
|
|
|
/// Second part of the template for equally-sized case, accessing a single
|
|
|
|
/// element:
|
|
|
|
/// {0} is either 'operand' or 'result'.
|
|
|
|
constexpr const char *opVariadicEqualSimpleTemplate = R"Py(
|
|
|
|
return self.operation.{0}s[start]
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Second part of the template for equally-sized case, accessing a variadic
|
|
|
|
/// group:
|
|
|
|
/// {0} is either 'operand' or 'result'.
|
|
|
|
constexpr const char *opVariadicEqualVariadicTemplate = R"Py(
|
|
|
|
return self.operation.{0}s[start:start + pg]
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for an attribute-sized group accessor:
|
|
|
|
/// {0} is the name of the accessor;
|
|
|
|
/// {1} is either 'operand' or 'result';
|
|
|
|
/// {2} is the position of the group in the group list;
|
|
|
|
/// {3} is a return suffix (expected [0] for single-element, empty for
|
|
|
|
/// variadic, and opVariadicSegmentOptionalTrailingTemplate for optional).
|
|
|
|
constexpr const char *opVariadicSegmentTemplate = R"Py(
|
|
|
|
@property
|
|
|
|
def {0}(self):
|
2020-12-30 09:43:04 +08:00
|
|
|
{1}_range = _ods_segmented_accessor(
|
2020-11-10 00:29:21 +08:00
|
|
|
self.operation.{1}s,
|
|
|
|
self.operation.attributes["{1}_segment_sizes"], {2})
|
|
|
|
return {1}_range{3}
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for a suffix when accessing an optional element in the
|
|
|
|
/// attribute-sized case:
|
|
|
|
/// {0} is either 'operand' or 'result';
|
|
|
|
constexpr const char *opVariadicSegmentOptionalTrailingTemplate =
|
|
|
|
R"Py([0] if len({0}_range) > 0 else None)Py";
|
|
|
|
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
/// Template for an operation attribute getter:
|
|
|
|
/// {0} is the name of the attribute sanitized for Python;
|
|
|
|
/// {1} is the Python type of the attribute;
|
|
|
|
/// {2} os the original name of the attribute.
|
|
|
|
constexpr const char *attributeGetterTemplate = R"Py(
|
|
|
|
@property
|
|
|
|
def {0}(self):
|
|
|
|
return {1}(self.operation.attributes["{2}"])
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for an optional operation attribute getter:
|
|
|
|
/// {0} is the name of the attribute sanitized for Python;
|
|
|
|
/// {1} is the Python type of the attribute;
|
|
|
|
/// {2} is the original name of the attribute.
|
|
|
|
constexpr const char *optionalAttributeGetterTemplate = R"Py(
|
|
|
|
@property
|
|
|
|
def {0}(self):
|
|
|
|
if "{2}" not in self.operation.attributes:
|
|
|
|
return None
|
|
|
|
return {1}(self.operation.attributes["{2}"])
|
|
|
|
)Py";
|
|
|
|
|
2020-11-18 01:28:16 +08:00
|
|
|
/// Template for a getter of a unit operation attribute, returns True of the
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
/// unit attribute is present, False otherwise (unit attributes have meaning
|
|
|
|
/// by mere presence):
|
|
|
|
/// {0} is the name of the attribute sanitized for Python,
|
|
|
|
/// {1} is the original name of the attribute.
|
|
|
|
constexpr const char *unitAttributeGetterTemplate = R"Py(
|
|
|
|
@property
|
|
|
|
def {0}(self):
|
|
|
|
return "{1}" in self.operation.attributes
|
|
|
|
)Py";
|
|
|
|
|
2020-11-18 01:28:16 +08:00
|
|
|
/// Template for an operation attribute setter:
|
|
|
|
/// {0} is the name of the attribute sanitized for Python;
|
|
|
|
/// {1} is the original name of the attribute.
|
|
|
|
constexpr const char *attributeSetterTemplate = R"Py(
|
|
|
|
@{0}.setter
|
|
|
|
def {0}(self, value):
|
|
|
|
if value is None:
|
|
|
|
raise ValueError("'None' not allowed as value for mandatory attributes")
|
|
|
|
self.operation.attributes["{1}"] = value
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for a setter of an optional operation attribute, setting to None
|
|
|
|
/// removes the attribute:
|
|
|
|
/// {0} is the name of the attribute sanitized for Python;
|
|
|
|
/// {1} is the original name of the attribute.
|
|
|
|
constexpr const char *optionalAttributeSetterTemplate = R"Py(
|
|
|
|
@{0}.setter
|
|
|
|
def {0}(self, value):
|
|
|
|
if value is not None:
|
|
|
|
self.operation.attributes["{1}"] = value
|
|
|
|
elif "{1}" in self.operation.attributes:
|
|
|
|
del self.operation.attributes["{1}"]
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for a setter of a unit operation attribute, setting to None or
|
|
|
|
/// False removes the attribute:
|
|
|
|
/// {0} is the name of the attribute sanitized for Python;
|
|
|
|
/// {1} is the original name of the attribute.
|
|
|
|
constexpr const char *unitAttributeSetterTemplate = R"Py(
|
|
|
|
@{0}.setter
|
|
|
|
def {0}(self, value):
|
|
|
|
if bool(value):
|
2020-12-30 09:43:04 +08:00
|
|
|
self.operation.attributes["{1}"] = _ods_ir.UnitAttr.get()
|
2020-11-18 01:28:16 +08:00
|
|
|
elif "{1}" in self.operation.attributes:
|
|
|
|
del self.operation.attributes["{1}"]
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for a deleter of an optional or a unit operation attribute, removes
|
|
|
|
/// the attribute from the operation:
|
|
|
|
/// {0} is the name of the attribute sanitized for Python;
|
|
|
|
/// {1} is the original name of the attribute.
|
|
|
|
constexpr const char *attributeDeleterTemplate = R"Py(
|
|
|
|
@{0}.deleter
|
|
|
|
def {0}(self):
|
|
|
|
del self.operation.attributes["{1}"]
|
|
|
|
)Py";
|
|
|
|
|
2020-11-10 00:29:21 +08:00
|
|
|
static llvm::cl::OptionCategory
|
|
|
|
clOpPythonBindingCat("Options for -gen-python-op-bindings");
|
|
|
|
|
|
|
|
static llvm::cl::opt<std::string>
|
|
|
|
clDialectName("bind-dialect",
|
|
|
|
llvm::cl::desc("The dialect to run the generator for"),
|
|
|
|
llvm::cl::init(""), llvm::cl::cat(clOpPythonBindingCat));
|
|
|
|
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
using AttributeClasses = DenseMap<StringRef, StringRef>;
|
|
|
|
|
2020-11-10 00:29:21 +08:00
|
|
|
/// Checks whether `str` is a Python keyword.
|
|
|
|
static bool isPythonKeyword(StringRef str) {
|
|
|
|
static llvm::StringSet<> keywords(
|
|
|
|
{"and", "as", "assert", "break", "class", "continue",
|
|
|
|
"def", "del", "elif", "else", "except", "finally",
|
|
|
|
"for", "from", "global", "if", "import", "in",
|
|
|
|
"is", "lambda", "nonlocal", "not", "or", "pass",
|
|
|
|
"raise", "return", "try", "while", "with", "yield"});
|
|
|
|
return keywords.contains(str);
|
2021-01-19 13:59:15 +08:00
|
|
|
}
|
2020-11-10 00:29:21 +08:00
|
|
|
|
2020-12-30 09:43:04 +08:00
|
|
|
/// Checks whether `str` would shadow a generated variable or attribute
|
|
|
|
/// part of the OpView API.
|
|
|
|
static bool isODSReserved(StringRef str) {
|
|
|
|
static llvm::StringSet<> reserved(
|
|
|
|
{"attributes", "create", "context", "ip", "operands", "print", "get_asm",
|
|
|
|
"loc", "verify", "regions", "result", "results", "self", "operation",
|
|
|
|
"DIALECT_NAMESPACE", "OPERATION_NAME"});
|
|
|
|
return str.startswith("_ods_") || str.endswith("_ods") ||
|
|
|
|
reserved.contains(str);
|
|
|
|
}
|
|
|
|
|
2020-11-10 00:29:21 +08:00
|
|
|
/// Modifies the `name` in a way that it becomes suitable for Python bindings
|
|
|
|
/// (does not change the `name` if it already is suitable) and returns the
|
|
|
|
/// modified version.
|
|
|
|
static std::string sanitizeName(StringRef name) {
|
2020-12-30 09:43:04 +08:00
|
|
|
if (isPythonKeyword(name) || isODSReserved(name))
|
2020-11-10 00:29:21 +08:00
|
|
|
return (name + "_").str();
|
|
|
|
return name.str();
|
|
|
|
}
|
|
|
|
|
2020-11-11 00:31:36 +08:00
|
|
|
static std::string attrSizedTraitForKind(const char *kind) {
|
|
|
|
return llvm::formatv("::mlir::OpTrait::AttrSized{0}{1}Segments",
|
|
|
|
llvm::StringRef(kind).take_front().upper(),
|
|
|
|
llvm::StringRef(kind).drop_front());
|
|
|
|
}
|
|
|
|
|
2020-11-10 00:29:21 +08:00
|
|
|
/// Emits accessors to "elements" of an Op definition. Currently, the supported
|
|
|
|
/// elements are operands and results, indicated by `kind`, which must be either
|
|
|
|
/// `operand` or `result` and is used verbatim in the emitted code.
|
|
|
|
static void emitElementAccessors(
|
|
|
|
const Operator &op, raw_ostream &os, const char *kind,
|
|
|
|
llvm::function_ref<unsigned(const Operator &)> getNumVariadic,
|
|
|
|
llvm::function_ref<int(const Operator &)> getNumElements,
|
|
|
|
llvm::function_ref<const NamedTypeConstraint &(const Operator &, int)>
|
|
|
|
getElement) {
|
|
|
|
assert(llvm::is_contained(
|
|
|
|
llvm::SmallVector<StringRef, 2>{"operand", "result"}, kind) &&
|
|
|
|
"unsupported kind");
|
|
|
|
|
|
|
|
// Traits indicating how to process variadic elements.
|
|
|
|
std::string sameSizeTrait =
|
|
|
|
llvm::formatv("::mlir::OpTrait::SameVariadic{0}{1}Size",
|
|
|
|
llvm::StringRef(kind).take_front().upper(),
|
|
|
|
llvm::StringRef(kind).drop_front());
|
2020-11-11 00:31:36 +08:00
|
|
|
std::string attrSizedTrait = attrSizedTraitForKind(kind);
|
2020-11-10 00:29:21 +08:00
|
|
|
|
|
|
|
unsigned numVariadic = getNumVariadic(op);
|
|
|
|
|
|
|
|
// If there is only one variadic element group, its size can be inferred from
|
|
|
|
// the total number of elements. If there are none, the generation is
|
|
|
|
// straightforward.
|
|
|
|
if (numVariadic <= 1) {
|
|
|
|
bool seenVariableLength = false;
|
|
|
|
for (int i = 0, e = getNumElements(op); i < e; ++i) {
|
|
|
|
const NamedTypeConstraint &element = getElement(op, i);
|
|
|
|
if (element.isVariableLength())
|
|
|
|
seenVariableLength = true;
|
|
|
|
if (element.name.empty())
|
|
|
|
continue;
|
|
|
|
if (element.isVariableLength()) {
|
|
|
|
os << llvm::formatv(element.isOptional() ? opOneOptionalTemplate
|
|
|
|
: opOneVariadicTemplate,
|
|
|
|
sanitizeName(element.name), kind,
|
|
|
|
getNumElements(op), i);
|
|
|
|
} else if (seenVariableLength) {
|
|
|
|
os << llvm::formatv(opSingleAfterVariableTemplate,
|
|
|
|
sanitizeName(element.name), kind,
|
|
|
|
getNumElements(op), i);
|
|
|
|
} else {
|
|
|
|
os << llvm::formatv(opSingleTemplate, sanitizeName(element.name), kind,
|
|
|
|
i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Handle the operations where variadic groups have the same size.
|
|
|
|
if (op.getTrait(sameSizeTrait)) {
|
|
|
|
int numPrecedingSimple = 0;
|
|
|
|
int numPrecedingVariadic = 0;
|
|
|
|
for (int i = 0, e = getNumElements(op); i < e; ++i) {
|
|
|
|
const NamedTypeConstraint &element = getElement(op, i);
|
|
|
|
if (!element.name.empty()) {
|
|
|
|
os << llvm::formatv(opVariadicEqualPrefixTemplate,
|
|
|
|
sanitizeName(element.name), kind, numVariadic,
|
|
|
|
numPrecedingSimple, numPrecedingVariadic);
|
|
|
|
os << llvm::formatv(element.isVariableLength()
|
|
|
|
? opVariadicEqualVariadicTemplate
|
|
|
|
: opVariadicEqualSimpleTemplate,
|
|
|
|
kind);
|
|
|
|
}
|
|
|
|
if (element.isVariableLength())
|
|
|
|
++numPrecedingVariadic;
|
|
|
|
else
|
|
|
|
++numPrecedingSimple;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Handle the operations where the size of groups (variadic or not) is
|
|
|
|
// provided as an attribute. For non-variadic elements, make sure to return
|
|
|
|
// an element rather than a singleton container.
|
|
|
|
if (op.getTrait(attrSizedTrait)) {
|
|
|
|
for (int i = 0, e = getNumElements(op); i < e; ++i) {
|
|
|
|
const NamedTypeConstraint &element = getElement(op, i);
|
|
|
|
if (element.name.empty())
|
|
|
|
continue;
|
|
|
|
std::string trailing;
|
|
|
|
if (!element.isVariableLength())
|
|
|
|
trailing = "[0]";
|
|
|
|
else if (element.isOptional())
|
|
|
|
trailing = std::string(
|
|
|
|
llvm::formatv(opVariadicSegmentOptionalTrailingTemplate, kind));
|
|
|
|
os << llvm::formatv(opVariadicSegmentTemplate, sanitizeName(element.name),
|
|
|
|
kind, i, trailing);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::PrintFatalError("unsupported " + llvm::Twine(kind) + " structure");
|
|
|
|
}
|
|
|
|
|
2020-11-11 00:31:36 +08:00
|
|
|
/// Free function helpers accessing Operator components.
|
|
|
|
static int getNumOperands(const Operator &op) { return op.getNumOperands(); }
|
|
|
|
static const NamedTypeConstraint &getOperand(const Operator &op, int i) {
|
|
|
|
return op.getOperand(i);
|
|
|
|
}
|
|
|
|
static int getNumResults(const Operator &op) { return op.getNumResults(); }
|
|
|
|
static const NamedTypeConstraint &getResult(const Operator &op, int i) {
|
|
|
|
return op.getResult(i);
|
|
|
|
}
|
|
|
|
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
/// Emits accessors to Op operands.
|
2020-11-10 00:29:21 +08:00
|
|
|
static void emitOperandAccessors(const Operator &op, raw_ostream &os) {
|
|
|
|
auto getNumVariadic = [](const Operator &oper) {
|
|
|
|
return oper.getNumVariableLengthOperands();
|
|
|
|
};
|
2020-11-11 00:31:36 +08:00
|
|
|
emitElementAccessors(op, os, "operand", getNumVariadic, getNumOperands,
|
|
|
|
getOperand);
|
2020-11-10 00:29:21 +08:00
|
|
|
}
|
|
|
|
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
/// Emits accessors Op results.
|
2020-11-10 00:29:21 +08:00
|
|
|
static void emitResultAccessors(const Operator &op, raw_ostream &os) {
|
|
|
|
auto getNumVariadic = [](const Operator &oper) {
|
|
|
|
return oper.getNumVariableLengthResults();
|
|
|
|
};
|
2020-11-11 00:31:36 +08:00
|
|
|
emitElementAccessors(op, os, "result", getNumVariadic, getNumResults,
|
|
|
|
getResult);
|
|
|
|
}
|
|
|
|
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
/// Emits accessors to Op attributes.
|
|
|
|
static void emitAttributeAccessors(const Operator &op,
|
|
|
|
const AttributeClasses &attributeClasses,
|
|
|
|
raw_ostream &os) {
|
|
|
|
for (const auto &namedAttr : op.getAttributes()) {
|
|
|
|
// Skip "derived" attributes because they are just C++ functions that we
|
|
|
|
// don't currently expose.
|
|
|
|
if (namedAttr.attr.isDerivedAttr())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (namedAttr.name.empty())
|
|
|
|
continue;
|
|
|
|
|
2020-11-18 01:28:16 +08:00
|
|
|
std::string sanitizedName = sanitizeName(namedAttr.name);
|
|
|
|
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
// Unit attributes are handled specially.
|
|
|
|
if (namedAttr.attr.getStorageType().trim().equals("::mlir::UnitAttr")) {
|
2020-11-18 01:28:16 +08:00
|
|
|
os << llvm::formatv(unitAttributeGetterTemplate, sanitizedName,
|
|
|
|
namedAttr.name);
|
|
|
|
os << llvm::formatv(unitAttributeSetterTemplate, sanitizedName,
|
|
|
|
namedAttr.name);
|
|
|
|
os << llvm::formatv(attributeDeleterTemplate, sanitizedName,
|
|
|
|
namedAttr.name);
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Other kinds of attributes need a mapping to a Python type.
|
|
|
|
if (!attributeClasses.count(namedAttr.attr.getStorageType().trim()))
|
|
|
|
continue;
|
|
|
|
|
2020-11-18 01:28:16 +08:00
|
|
|
StringRef pythonType =
|
|
|
|
attributeClasses.lookup(namedAttr.attr.getStorageType());
|
|
|
|
if (namedAttr.attr.isOptional()) {
|
|
|
|
os << llvm::formatv(optionalAttributeGetterTemplate, sanitizedName,
|
|
|
|
pythonType, namedAttr.name);
|
|
|
|
os << llvm::formatv(optionalAttributeSetterTemplate, sanitizedName,
|
|
|
|
namedAttr.name);
|
|
|
|
os << llvm::formatv(attributeDeleterTemplate, sanitizedName,
|
|
|
|
namedAttr.name);
|
|
|
|
} else {
|
|
|
|
os << llvm::formatv(attributeGetterTemplate, sanitizedName, pythonType,
|
|
|
|
namedAttr.name);
|
|
|
|
os << llvm::formatv(attributeSetterTemplate, sanitizedName,
|
|
|
|
namedAttr.name);
|
|
|
|
// Non-optional attributes cannot be deleted.
|
|
|
|
}
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-11 00:31:36 +08:00
|
|
|
/// Template for the default auto-generated builder.
|
2021-01-19 03:27:19 +08:00
|
|
|
/// {0} is a comma-separated list of builder arguments, including the trailing
|
2020-11-11 00:31:36 +08:00
|
|
|
/// `loc` and `ip`;
|
2021-01-19 03:27:19 +08:00
|
|
|
/// {1} is the code populating `operands`, `results` and `attributes` fields.
|
2020-11-11 00:31:36 +08:00
|
|
|
constexpr const char *initTemplate = R"Py(
|
2021-01-19 03:27:19 +08:00
|
|
|
def __init__(self, {0}):
|
2020-11-11 00:31:36 +08:00
|
|
|
operands = []
|
|
|
|
results = []
|
|
|
|
attributes = {{}
|
2021-01-19 03:27:19 +08:00
|
|
|
{1}
|
|
|
|
super().__init__(self._ods_build_default(
|
|
|
|
attributes=attributes, operands=operands, results=results,
|
2020-11-11 00:31:36 +08:00
|
|
|
loc=loc, ip=ip))
|
|
|
|
)Py";
|
|
|
|
|
|
|
|
/// Template for appending a single element to the operand/result list.
|
|
|
|
/// {0} is either 'operand' or 'result';
|
|
|
|
/// {1} is the field name.
|
|
|
|
constexpr const char *singleElementAppendTemplate = "{0}s.append({1})";
|
|
|
|
|
|
|
|
/// Template for appending an optional element to the operand/result list.
|
|
|
|
/// {0} is either 'operand' or 'result';
|
|
|
|
/// {1} is the field name.
|
|
|
|
constexpr const char *optionalAppendTemplate =
|
|
|
|
"if {1} is not None: {0}s.append({1})";
|
|
|
|
|
2021-01-19 03:27:19 +08:00
|
|
|
/// Template for appending a a list of elements to the operand/result list.
|
2020-11-11 00:31:36 +08:00
|
|
|
/// {0} is either 'operand' or 'result';
|
|
|
|
/// {1} is the field name.
|
2021-01-19 03:27:19 +08:00
|
|
|
constexpr const char *multiElementAppendTemplate = "{0}s.extend({1})";
|
2020-11-11 00:31:36 +08:00
|
|
|
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
/// Template for setting an attribute in the operation builder.
|
|
|
|
/// {0} is the attribute name;
|
|
|
|
/// {1} is the builder argument name.
|
|
|
|
constexpr const char *initAttributeTemplate = R"Py(attributes["{0}"] = {1})Py";
|
|
|
|
|
|
|
|
/// Template for setting an optional attribute in the operation builder.
|
|
|
|
/// {0} is the attribute name;
|
|
|
|
/// {1} is the builder argument name.
|
|
|
|
constexpr const char *initOptionalAttributeTemplate =
|
|
|
|
R"Py(if {1} is not None: attributes["{0}"] = {1})Py";
|
|
|
|
|
|
|
|
constexpr const char *initUnitAttributeTemplate =
|
2020-12-30 09:43:04 +08:00
|
|
|
R"Py(if bool({1}): attributes["{0}"] = _ods_ir.UnitAttr.get(
|
|
|
|
_ods_get_default_loc_context(loc)))Py";
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
|
|
|
|
/// Populates `builderArgs` with the Python-compatible names of builder function
|
|
|
|
/// arguments, first the results, then the intermixed attributes and operands in
|
|
|
|
/// the same order as they appear in the `arguments` field of the op definition.
|
|
|
|
/// Additionally, `operandNames` is populated with names of operands in their
|
|
|
|
/// order of appearance.
|
|
|
|
static void
|
|
|
|
populateBuilderArgs(const Operator &op,
|
|
|
|
llvm::SmallVectorImpl<std::string> &builderArgs,
|
|
|
|
llvm::SmallVectorImpl<std::string> &operandNames) {
|
|
|
|
for (int i = 0, e = op.getNumResults(); i < e; ++i) {
|
|
|
|
std::string name = op.getResultName(i).str();
|
|
|
|
if (name.empty())
|
|
|
|
name = llvm::formatv("_gen_res_{0}", i);
|
|
|
|
name = sanitizeName(name);
|
|
|
|
builderArgs.push_back(name);
|
|
|
|
}
|
|
|
|
for (int i = 0, e = op.getNumArgs(); i < e; ++i) {
|
|
|
|
std::string name = op.getArgName(i).str();
|
|
|
|
if (name.empty())
|
|
|
|
name = llvm::formatv("_gen_arg_{0}", i);
|
|
|
|
name = sanitizeName(name);
|
|
|
|
builderArgs.push_back(name);
|
|
|
|
if (!op.getArg(i).is<NamedAttribute *>())
|
|
|
|
operandNames.push_back(name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Populates `builderLines` with additional lines that are required in the
|
|
|
|
/// builder to set up operation attributes. `argNames` is expected to contain
|
|
|
|
/// the names of builder arguments that correspond to op arguments, i.e. to the
|
|
|
|
/// operands and attributes in the same order as they appear in the `arguments`
|
|
|
|
/// field.
|
|
|
|
static void
|
|
|
|
populateBuilderLinesAttr(const Operator &op,
|
|
|
|
llvm::ArrayRef<std::string> argNames,
|
|
|
|
llvm::SmallVectorImpl<std::string> &builderLines) {
|
|
|
|
for (int i = 0, e = op.getNumArgs(); i < e; ++i) {
|
|
|
|
Argument arg = op.getArg(i);
|
|
|
|
auto *attribute = arg.dyn_cast<NamedAttribute *>();
|
|
|
|
if (!attribute)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Unit attributes are handled specially.
|
|
|
|
if (attribute->attr.getStorageType().trim().equals("::mlir::UnitAttr")) {
|
|
|
|
builderLines.push_back(llvm::formatv(initUnitAttributeTemplate,
|
|
|
|
attribute->name, argNames[i]));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
builderLines.push_back(llvm::formatv(attribute->attr.isOptional()
|
|
|
|
? initOptionalAttributeTemplate
|
|
|
|
: initAttributeTemplate,
|
|
|
|
attribute->name, argNames[i]));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Populates `builderLines` with additional lines that are required in the
|
|
|
|
/// builder. `kind` must be either "operand" or "result". `names` contains the
|
|
|
|
/// names of init arguments that correspond to the elements.
|
2020-11-11 00:31:36 +08:00
|
|
|
static void populateBuilderLines(
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
const Operator &op, const char *kind, llvm::ArrayRef<std::string> names,
|
2020-11-11 00:31:36 +08:00
|
|
|
llvm::SmallVectorImpl<std::string> &builderLines,
|
|
|
|
llvm::function_ref<int(const Operator &)> getNumElements,
|
|
|
|
llvm::function_ref<const NamedTypeConstraint &(const Operator &, int)>
|
|
|
|
getElement) {
|
2021-01-19 03:27:19 +08:00
|
|
|
bool sizedSegments = op.getTrait(attrSizedTraitForKind(kind)) != nullptr;
|
2020-11-11 00:31:36 +08:00
|
|
|
|
|
|
|
// For each element, find or generate a name.
|
|
|
|
for (int i = 0, e = getNumElements(op); i < e; ++i) {
|
|
|
|
const NamedTypeConstraint &element = getElement(op, i);
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
std::string name = names[i];
|
2020-11-11 00:31:36 +08:00
|
|
|
|
|
|
|
// Choose the formatting string based on the element kind.
|
2021-01-19 03:27:19 +08:00
|
|
|
llvm::StringRef formatString;
|
2020-11-11 00:31:36 +08:00
|
|
|
if (!element.isVariableLength()) {
|
|
|
|
formatString = singleElementAppendTemplate;
|
|
|
|
} else if (element.isOptional()) {
|
|
|
|
formatString = optionalAppendTemplate;
|
|
|
|
} else {
|
|
|
|
assert(element.isVariadic() && "unhandled element group type");
|
2021-01-19 03:27:19 +08:00
|
|
|
// If emitting with sizedSegments, then we add the actual list typed
|
|
|
|
// element using the singleElementAppendTemplate. Otherwise, we extend
|
|
|
|
// the actual operands.
|
|
|
|
if (sizedSegments) {
|
|
|
|
// Append the list as is.
|
|
|
|
formatString = singleElementAppendTemplate;
|
|
|
|
} else {
|
|
|
|
// Append the list elements.
|
|
|
|
formatString = multiElementAppendTemplate;
|
|
|
|
}
|
2020-11-11 00:31:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Add the lines.
|
|
|
|
builderLines.push_back(llvm::formatv(formatString.data(), kind, name));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Emits a default builder constructing an operation from the list of its
|
|
|
|
/// result types, followed by a list of its operands.
|
|
|
|
static void emitDefaultOpBuilder(const Operator &op, raw_ostream &os) {
|
|
|
|
// If we are asked to skip default builders, comply.
|
|
|
|
if (op.skipDefaultBuilders())
|
|
|
|
return;
|
|
|
|
|
|
|
|
llvm::SmallVector<std::string, 8> builderArgs;
|
|
|
|
llvm::SmallVector<std::string, 8> builderLines;
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
llvm::SmallVector<std::string, 4> operandArgNames;
|
|
|
|
builderArgs.reserve(op.getNumOperands() + op.getNumResults() +
|
|
|
|
op.getNumNativeAttributes());
|
|
|
|
populateBuilderArgs(op, builderArgs, operandArgNames);
|
|
|
|
populateBuilderLines(
|
|
|
|
op, "result",
|
|
|
|
llvm::makeArrayRef(builderArgs).take_front(op.getNumResults()),
|
|
|
|
builderLines, getNumResults, getResult);
|
|
|
|
populateBuilderLines(op, "operand", operandArgNames, builderLines,
|
2020-11-11 00:31:36 +08:00
|
|
|
getNumOperands, getOperand);
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
populateBuilderLinesAttr(
|
|
|
|
op, llvm::makeArrayRef(builderArgs).drop_front(op.getNumResults()),
|
|
|
|
builderLines);
|
2020-11-11 00:31:36 +08:00
|
|
|
|
|
|
|
builderArgs.push_back("loc=None");
|
|
|
|
builderArgs.push_back("ip=None");
|
2021-01-19 03:27:19 +08:00
|
|
|
os << llvm::formatv(initTemplate, llvm::join(builderArgs, ", "),
|
2020-11-11 00:31:36 +08:00
|
|
|
llvm::join(builderLines, "\n "));
|
2020-11-10 00:29:21 +08:00
|
|
|
}
|
|
|
|
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
static void constructAttributeMapping(const llvm::RecordKeeper &records,
|
|
|
|
AttributeClasses &attributeClasses) {
|
|
|
|
for (const llvm::Record *rec :
|
|
|
|
records.getAllDerivedDefinitions("PythonAttr")) {
|
|
|
|
attributeClasses.try_emplace(rec->getValueAsString("cppStorageType").trim(),
|
|
|
|
rec->getValueAsString("pythonType").trim());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-01-19 03:27:19 +08:00
|
|
|
static void emitSegmentSpec(
|
|
|
|
const Operator &op, const char *kind,
|
|
|
|
llvm::function_ref<int(const Operator &)> getNumElements,
|
|
|
|
llvm::function_ref<const NamedTypeConstraint &(const Operator &, int)>
|
|
|
|
getElement,
|
|
|
|
raw_ostream &os) {
|
|
|
|
std::string segmentSpec("[");
|
|
|
|
for (int i = 0, e = getNumElements(op); i < e; ++i) {
|
|
|
|
const NamedTypeConstraint &element = getElement(op, i);
|
|
|
|
if (element.isVariableLength()) {
|
|
|
|
segmentSpec.append("-1,");
|
|
|
|
} else if (element.isOptional()) {
|
|
|
|
segmentSpec.append("0,");
|
|
|
|
} else {
|
|
|
|
segmentSpec.append("1,");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
segmentSpec.append("]");
|
|
|
|
|
|
|
|
os << llvm::formatv(opClassSizedSegmentsTemplate, kind, segmentSpec);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void emitRegionAttributes(const Operator &op, raw_ostream &os) {
|
|
|
|
// Emit _ODS_REGIONS = (min_region_count, has_no_variadic_regions).
|
|
|
|
// Note that the base OpView class defines this as (0, True).
|
|
|
|
unsigned minRegionCount = op.getNumRegions() - op.getNumVariadicRegions();
|
|
|
|
os << llvm::formatv(opClassRegionSpecTemplate, minRegionCount,
|
|
|
|
op.hasNoVariadicRegions() ? "True" : "False");
|
|
|
|
}
|
|
|
|
|
2020-11-10 00:29:21 +08:00
|
|
|
/// Emits bindings for a specific Op to the given output stream.
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
static void emitOpBindings(const Operator &op,
|
|
|
|
const AttributeClasses &attributeClasses,
|
|
|
|
raw_ostream &os) {
|
2020-11-10 00:29:21 +08:00
|
|
|
os << llvm::formatv(opClassTemplate, op.getCppClassName(),
|
|
|
|
op.getOperationName());
|
2021-01-19 03:27:19 +08:00
|
|
|
|
|
|
|
// Sized segments.
|
|
|
|
if (op.getTrait(attrSizedTraitForKind("operand")) != nullptr) {
|
|
|
|
emitSegmentSpec(op, "OPERAND", getNumOperands, getOperand, os);
|
|
|
|
}
|
|
|
|
if (op.getTrait(attrSizedTraitForKind("result")) != nullptr) {
|
|
|
|
emitSegmentSpec(op, "RESULT", getNumResults, getResult, os);
|
|
|
|
}
|
|
|
|
|
|
|
|
emitRegionAttributes(op, os);
|
2020-11-11 00:31:36 +08:00
|
|
|
emitDefaultOpBuilder(op, os);
|
2020-11-10 00:29:21 +08:00
|
|
|
emitOperandAccessors(op, os);
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
emitAttributeAccessors(op, attributeClasses, os);
|
2020-11-10 00:29:21 +08:00
|
|
|
emitResultAccessors(op, os);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Emits bindings for the dialect specified in the command line, including file
|
|
|
|
/// headers and utilities. Returns `false` on success to comply with Tablegen
|
|
|
|
/// registration requirements.
|
|
|
|
static bool emitAllOps(const llvm::RecordKeeper &records, raw_ostream &os) {
|
|
|
|
if (clDialectName.empty())
|
|
|
|
llvm::PrintFatalError("dialect name not provided");
|
|
|
|
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
AttributeClasses attributeClasses;
|
|
|
|
constructAttributeMapping(records, attributeClasses);
|
|
|
|
|
2021-01-20 05:16:16 +08:00
|
|
|
os << llvm::formatv(fileHeader, clDialectName.getValue());
|
2020-11-10 00:29:21 +08:00
|
|
|
os << llvm::formatv(dialectClassTemplate, clDialectName.getValue());
|
|
|
|
for (const llvm::Record *rec : records.getAllDerivedDefinitions("Op")) {
|
|
|
|
Operator op(rec);
|
|
|
|
if (op.getDialectName() == clDialectName.getValue())
|
[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
2020-11-16 23:17:03 +08:00
|
|
|
emitOpBindings(op, attributeClasses, os);
|
2020-11-10 00:29:21 +08:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GenRegistration
|
|
|
|
genPythonBindings("gen-python-op-bindings",
|
|
|
|
"Generate Python bindings for MLIR Ops", &emitAllOps);
|