diff --git a/mlir/docs/DefiningDialects/Operations.md b/mlir/docs/DefiningDialects/Operations.md index 5ef0e6b5551d2e..8ff60ac21424c4 100644 --- a/mlir/docs/DefiningDialects/Operations.md +++ b/mlir/docs/DefiningDialects/Operations.md @@ -102,8 +102,9 @@ their semantics via a special [TableGen backend][TableGenBackend]: constraints over attributes. A notable subclass hierarchy is `Attr`, which stands for constraints for attributes whose values are of common types. * The `Property` class hierarchy: They are used to specify non-attribute-backed - properties that are inherent to operations. This will be expanded to a - `PropertyConstraint` class or something similar in the future. + properties that are inherent to operations. These properties can have + constraints imposed on them using the `predicate` field or the + `ConfinedProp` class. An operation is defined by specializing the `Op` class with concrete contents for all the fields it requires. For example, `tf.AvgPool` is defined as @@ -202,15 +203,15 @@ let arguments = (ins ... :$, ... - :$, + :$, ); ``` Here `` is a TableGen `def` from the `TypeConstraint` class hierarchy. Similarly, `` is a TableGen `def` from the -`AttrConstraint` class hierarchy and `` is a subclass -of `Property` (though a `PropertyConstraint` hierarchy is planned). -See [Constraints](#constraints) for more information. +`AttrConstraint` class hierarchy and `` is a subclass +of `Property` (constraints can be imposed onto it using its `predicate` field +or the `ConfinedProp` subclass). There is no requirements on the relative order of operands and attributes; they can mix freely. The relative order of operands themselves matters. From each