[mlir] Simplify DDR matching patterns with equal operands for operators where it's applicable.

[rdzhabarov]

Summary

This https://reviews.llvm.org/D89254 diff introduced implicit matching between same name operands.
Change docs and some usages accordingly.

[jpienaar]

Nice

mlir/docs/DeclarativeRewrites.md

142

s/automatic// ?

(and perhaps s/enforces/ensures/)

mlir/include/mlir/IR/OpBase.td

2294–2295

While here, seems bind fits the tense better.

2296

I'd differentiate here: for me (my mental model) is one operand is bound and the other(s) verified. Only one value has that name, the rest are just verified to be equal to it (conceptually they need never even be named or bound, and that we do today is an implementation detail).

2316

The above also changes this explanation here

[rdzhabarov]

commented.

mlir/include/mlir/IR/OpBase.td

2294–2295

sg

2296

I'm happy to change to what makes more sense.

Operands in the source pattern could have the same name. This makes one operand to be bound to that name and the rest verified to be equal.

Let me know.

[rdzhabarov]

comments.

[rdzhabarov]

fixed.

[rdzhabarov]

fix wording.

[jpienaar]

Nice, thanks!

mlir/include/mlir/IR/OpBase.td

2296

Looks good, minor nit: This bounds one operand to the name while verifying the rest are all equal? [the "to be bound" feels like it could be simplified and the previous is one suggestion]

[rdzhabarov]

comments.

mlir/docs/DeclarativeRewrites.md

 In the above, we are matching an `AOp` whose `$input` can be anything valid as
 defined by the op and whose `$attr` must be a float attribute. If the match
 succeeds, we bind the `$input` symbol to the op's only input (`$a_input`) and
 `$attr` to the only attribute (`$a_attr`); we can reference them using `$input`
 and `$attr` in result patterns and additional constraints.
 
 The pattern is position-based: the symbol names used for capturing here do not
 need to match with the op definition as shown in the above example. As another
-example, the pattern can be written as ` def : Pat<(AOp $a, F32Attr:$b), ...>;`
+example, the pattern can be written as `def : Pat<(AOp $a, F32Attr:$b), ...>;`
 and use `$a` and `$b` to refer to the captured input and attribute. But using
-the ODS name directly in the pattern is also allowed.
+the ODS name directly in the pattern is also allowed. Operands in the source
+pattern can have the same name. This bounds one operand to the name while
+verifying the rest are all equal.
 
 Also note that we only need to add `TypeConstraint` or `AttributeConstraint`
 when we need to further limit the match criteria. If all valid cases to the op
 are acceptable, then we can leave the constraint unspecified.
 
 `$_` is a special symbol to mean ignore capturing an argument. For example,
 `def : Pat<(AOp $_, $b), ...>` means only `$b` is interesting to capture and
 will be referenced later in result patterns. It's still possible to place

mlir/include/mlir/IR/OpBase.td

 // in the form of `(node arg0, arg1, ...)`.
 //
 // The `node` are normally MLIR ops, but it can also be one of the directives
 // listed later in this section.
 //
 // ## Symbol binding
 //
 // In the source pattern, `argN` can be used to specify matchers (e.g., using
 // type/attribute type constraints, etc.) and bound to a name for later use.
-// We can also bound names to op instances to reference them later in
-// multi-entity constraints.
+// We can also bind names to op instances to reference them later in
+// multi-entity constraints. Operands in the source pattern can have
+// the same name. This bounds one operand to the name while verifying
+// the rest are all equal.
+//
 //
 // In the result pattern, `argN` can be used to refer to a previously bound
 // name, with potential transformations (e.g., using tAttr, etc.). `argN` can
 // itself be nested DAG node. We can also bound names to ops to reference
 // them later in other result patterns.
 //
 // For example,
 //
 // ```
-// def : Pattern<(OneResultOp1:$op1 $arg0, $arg1),
+// def : Pattern<(OneResultOp1:$op1 $arg0, $arg1, $arg0),
 //               [(OneResultOp2:$op2 $arg0, $arg1),
 //                (OneResultOp3 $op2 (OneResultOp4))],
 //               [(HasStaticShapePred $op1)]>;
 // ```
 //
-// `$argN` is bound to the `OneResultOp1`'s N-th argument and used later to
-// build `OneResultOp2`. `$op1` is bound to `OneResultOp1` and used to
-// check whether the result's shape is static. `$op2` is bound to
-// `OneResultOp2` and used to build `OneResultOp3`.
+// First `$arg0` and '$arg1' are bound to the `OneResultOp1`'s first
+// and second arguments and used later to build `OneResultOp2`. Second '$arg0'
+// is verified to be equal to the first '$arg0' operand.
+// `$op1` is bound to `OneResultOp1` and used to check whether the result's
+// shape is static. `$op2` is bound to `OneResultOp2` and used to
+// build `OneResultOp3`.
 //
 // ## Multi-result op
 //
 // To create multi-result ops in result pattern, you can use a syntax similar
 // to uni-result op, and it will act as a value pack for all results:
 //
 // ```
 // def : Pattern<(ThreeResultOp ...),

mlir/lib/Dialect/Shape/IR/ShapeCanonicalization.td

 include "mlir/Dialect/Shape/IR/ShapeOps.td"
 
-def EqualBinaryOperands : Constraint<CPred<"$0 == $1">>;
-
 def AllInputShapesEq : Constraint<CPred< [{
   llvm::all_of($0, [&](mlir::Value val) {
     return $0[0] == val;
   })
 }]>>;
 
 // Canonicalization patterns.
 
-def CstrBroadcastableEqOps : Pat<(Shape_CstrBroadcastableOp:$op $lhs, $rhs),
-  (Shape_ConstWitnessOp ConstBoolAttrTrue),
-  [(EqualBinaryOperands $lhs, $rhs)]>;
+def CstrBroadcastableEqOps : Pat<(Shape_CstrBroadcastableOp:$op $x, $x),
+  (Shape_ConstWitnessOp ConstBoolAttrTrue)>;
 
 def CstrEqEqOps : Pat<(Shape_CstrEqOp:$op $shapes),
   (Shape_ConstWitnessOp ConstBoolAttrTrue),
   [(AllInputShapesEq $shapes)]>;
 
 def IndexToSizeToIndexCanonicalization : Pat<
   (Shape_SizeToIndexOp (Shape_IndexToSizeOp $arg)),
   (replaceWithValue $arg)>;
 
 def SizeToIndexToSizeCanonicalization : Pat<
   (Shape_IndexToSizeOp (Shape_SizeToIndexOp $arg)),
   (replaceWithValue $arg)>;