[PATCH] D76715: [mlir] Clarify constraint on derived attribute

[Jacques Pienaar via Phabricator via llvm-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG57ce79f74d27: [mlir] Clarify constraint on derived attribute (authored by jpienaar).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76715/new/

https://reviews.llvm.org/D76715

Files:
  mlir/docs/OpDefinitions.md
  mlir/include/mlir/IR/OpBase.td


Index: mlir/include/mlir/IR/OpBase.td
===================================================================
--- mlir/include/mlir/IR/OpBase.td
+++ mlir/include/mlir/IR/OpBase.td
@@ -1386,6 +1386,9 @@
 // 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;
Index: mlir/docs/OpDefinitions.md
===================================================================
--- mlir/docs/OpDefinitions.md
+++ mlir/docs/OpDefinitions.md
@@ -180,6 +180,10 @@
    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`:
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D76715.252417.patch
Type: text/x-patch
Size: 1249 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200324/09292d3e/attachment.bin>