[Mlir-commits] [mlir] [mlir][transform] Add an op for replacing values with function calls (PR #78398)

[Oleksandr Alex Zinenko]

================
@@ -26,4 +28,67 @@ def ApplyFuncToLLVMConversionPatternsOp : Op<Transform_Dialect,
   let assemblyFormat = "attr-dict";
 }
 
+def CastAndCallOp : Op<Transform_Dialect,
+    "func.cast_and_call",
+    [DeclareOpInterfaceMethods<TransformOpInterface>,
+     DeclareOpInterfaceMethods<MemoryEffectsOpInterface>,
+     AttrSizedOperandSegments,
+     ReportTrackingListenerFailuresOpTrait]
+        # GraphRegionNoTerminator.traits> {
+  let summary = "Casts values to the signature of a function and replaces them "
+                "with a call";
+  let description = [{
+    This transform takes a set of |input| and |output| value handles and
+    attempts to cast them to the function signature of the attached function
+    op, then builds a call to the function and replaces the users of the
+    outputs. It is the responsibility of the user to ensure that the slice of
+    the program replaced by this operation makes sense, i.e. there is no
+    verification that the inputs to this operation have any relation to the
+    outputs outside of basic dominance requirements needed for the replacement.
+
+    The casting materialization functions are specified in the graph region of
+    this op. They must implement the `TypeConversionOpInterface`. The order of
+    ops within the region is irrelevant.
+
+    The target function can be specified by a symbol name or by a handle to the
+    operation.
+
+    This transform only reads the target handles and only replaces the users of
+    the outputs with the results of the call. No handles are consumed and no
+    operations are removed. Users are expected to run cleanup separately if
+    desired.
----------------
ftynse wrote:

Invalidation is primarily meant to avoid the dangling-reference situation and secondarily to catch invariant violations. If we had a type along the lines of "a payload operation using a value produced by arithmetic ops" (some affine operations are like this), we'd want to invalidate that one since the invariant no longer holds. Similarly, I don't think that we necessarily want to invalidate a handle to the `%0` value (we don't have handles to OpOperands, those would have to be invalidated): the value still exists, and we haven't made any strong promises about it. Maybe what I'm arguing for here is that we can occasionally re-run the verifier that checks if the contents of a handle corresponds to its type, which is currently different from invalidation. And maybe we should merge this process with invalidation, i.e., failing the conditions specified by the handle type invalidates the handle.

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