[llvm] [mlir][bufferization][NFC] Rename copy_tensor op to materialize_in_destination (PR #65467)

Matthias Springer via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 12 05:16:15 PDT 2023

@@ -209,17 +209,30 @@ def Bufferization_CloneOp : Bufferization_Op<"clone", [
-// CopyTensorOp
+// MaterializeInDestinationOp
-def Bufferization_CopyTensorOp : Bufferization_Op<"copy_tensor",
-    [BufferizableOpInterface, SameOperandsAndResultType,
-     DeclareOpInterfaceMethods<ReifyRankedShapedTypeOpInterface>]> {
+def Bufferization_MaterializeInDestinationOp
+    : Bufferization_Op<"materialize_in_destination",
+        [BufferizableOpInterface, SameOperandsAndResultType,
+         DeclareOpInterfaceMethods<ReifyRankedShapedTypeOpInterface>]> {
   let summary = "copy a tensor";
   let description = [{
-    Copy the contents of the source tensor into the destination tensor. This
-    operation is guaranteed to bufferize to a memory copy.
+    This op indicates that the data of the `source` tensor should materialize
+    in the future buffer of the `dest` tensors. Both tensors must have the same
+    shape and element type at runtime.
+    By default, this op bufferizes to a memcpy from the future buffer of the
+    `source` tensor to the future buffer of the `dest` tensor. However,
+    transformations such as "empty tensor elimination" may rewrite IR such that
+    a computation is performed directly in the future buffer of the `dest`
+    tensor and no memcpy is needed.
+    Note: "tensor.insert_slice" could be used for the same purpose, but since
+    tensor dialect ops only indicate *what* should be computed but not *where*,
+    it could fold away, causing the computation to materialize in a different
+    buffer.
matthias-springer wrote:

It could lower to something like `memref.memcpy %x, %x`. That's the case when the source and the destination tensor are equivalent. E.g.:
%0 = arith.select %c, %t, %t
%1 = bufferization.materialize_in_destination %0 into %t
In the above example that's easy to see and it could fold away, but it may not obvious in more complex cases (e.g., with tiling, nested loops, etc.).


More information about the llvm-commits mailing list