[mlir] Clarify constraint on derived attribute

[jpienaar]

Summary

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

[rriddle]

mlir/docs/OpDefinitions.md

183

Why is this indented?

mlir/include/mlir/IR/OpBase.td

1390

typo: used

[jpienaar]

Fix typo

mlir/docs/OpDefinitions.md

183

It is a second paragraph under the numbered list item.

mlir/docs/OpDefinitions.md

 
 1. Natural attributes: these attributes affect the behavior of the operations
    (e.g., padding for convolution);
 1. Derived attributes: these attributes are not needed to define the operation
    but are instead derived from information of the operation. E.g., the output
    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`:
 
 ```tablegen
 let arguments = (ins
   <type-constraint>:$<operand-name>,
   ...
   <attr-constraint>:$<attr-name>,

mlir/include/mlir/IR/OpBase.td

 }
 
 //===----------------------------------------------------------------------===//
 // Derive attribute kinds
 
 // 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;
 }
 
 // Derived attribute that returns a mlir::Type.
 class DerivedTypeAttr<code body> : DerivedAttr<"Type", body>;