[Mlir-commits] [mlir] [mlir][transform] Add an op for replacing values with function calls (PR #78398)
Quinn Dawkins
llvmlistbot at llvm.org
Wed Jan 17 09:36:38 PST 2024
================
@@ -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.
----------------
qedawkins wrote:
I see, this makes more sense then. IIUC there are no in-tree examples of something like "a payload operation using a value produced by arithmetic ops" then? (people could have written anything downstream). So would it suffice for now to leave a warning in the op description that such cases currently won't properly track invalidation? And then adding additional verification/invalidation mechanisms can come as a follow up?
https://github.com/llvm/llvm-project/pull/78398
More information about the Mlir-commits
mailing list