[llvm-branch-commits] [mlir] [mlir] Add predicates to tablegen-defined properties (PR #120176)

[Markus Böck via llvm-branch-commits]

================
@@ -63,6 +65,12 @@ class Property<string storageTypeParam = "", string desc = ""> {
     return convertFromAttribute($_storage, $_attr, $_diag);
   }];
 
+  // The verification predicate for this property. Defaults to And<[]>,
+  // which is trivially true, since properties are always their expected type.
+  // Within the predicate, `$_self` is an instance of the **interface**
+  // type of the property.
+  Pred predicate = ?;
----------------
zero9178 wrote:

I thought about it some more and pros- and cons in my head are:
* If you want to optimize the TableGen code such that the code is less (using the various `!if` constructs seen here), both `?` and `And<[]>` semantically are just as capable as they can both be checked for (`!initialized` and `!eq`) and special cased. Admittedly, I think that choosing `And<[]>` as the canonical "true" representation is more arbitrary, but both are to an extent and it is only for "readability of the outputted C++" optimization anyways. It could also be mitigated by defining `defvar True = And<[]>`, making it more readable.
* The con of `?` is that it **requires** classes such as `Optional` to special case `?`, while the `And<[]>` representation would not, making it purely an opt-in optimization, and not a semantic requirement for composing properties. 

Due to the last point I am therefore still leaning towards `And<[]>` as default. I also think in an ideal world it is the backend emitter that would optimize this but that is besides the point.
Would also love to hear other's opinion as I could live with the `?` default if others feel more strongly about it.

https://github.com/llvm/llvm-project/pull/120176