Magic-Mirror/llvm-capstone
1
0
Fork 0
mirror of https://github.com/capstone-engine/llvm-capstone.git synced 2025-01-07 00:23:43 +00:00
Code Issues Actions 4 Packages Projects Releases Wiki Activity

[mlir] Clarify constraint on derived attribute

Browse Source 
Summary:
The restriction that a derived attribute should represent an
attribute/be materializable as an attribute was not made clear.

Differential Revision: https://reviews.llvm.org/D76715
This commit is contained in:
Jacques Pienaar 2020-03-24 10:18:46 -07:00
parent 03e29e2c19
commit 57ce79f74d
2 changed files with 7 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
mlir/docs/OpDefinitions.md
View File

@ -180,6 +180,10 @@ values, including two categories:
shape of type. This is mostly used for convenience interface generation or
interaction with other frameworks/translation.
All derived attributes should be materializable as an Attribute. That is,
even though they are not materialized, it should be possible to store as
an attribute.
Both operands and attributes are specified inside the `dag`-typed `arguments`,
led by `ins`:

3
mlir/include/mlir/IR/OpBase.td
View File

@ -1386,6 +1386,9 @@ def SymbolRefArrayAttr :
// DerivedAttr are attributes whose value is computed from properties
// of the operation. They do not require additional storage and are
// materialized as needed.
// Note: All derived attributes should be materializable as an Attribute. E.g.,
// do not use DerivedAttr for things that could not have been stored as
// Attribute.
class DerivedAttr<code ret, code b> : Attr<CPred<"true">, "derived attribute"> {
let returnType = ret;
code body = b;