Skip to content

[mlir][NFC] Document predicate field on properties #120975

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 23, 2024
Merged

[mlir][NFC] Document predicate field on properties #120975

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 7 additions & 6 deletions mlir/docs/DefiningDialects/Operations.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -202,15 +203,15 @@ let arguments = (ins
...
<attr-constraint>:$<attr-name>,
...
<property-constraint>:$<property-name>,
<property>:$<property-name>,
);
```

Here `<type-constraint>` is a TableGen `def` from the `TypeConstraint` class
hierarchy. Similarly, `<attr-constraint>` is a TableGen `def` from the
`AttrConstraint` class hierarchy and `<property-constraint>` is a subclass
of `Property` (though a `PropertyConstraint` hierarchy is planned).
See [Constraints](#constraints) for more information.
`AttrConstraint` class hierarchy and `<property>` 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
Expand Down
Loading