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

Martin Erhart via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 12 04:10:41 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.
maerhart wrote:

If this lowers to a memcpy doesn't it also materialize in a different buffer? Do you maybe have a concrete example in mind that you could add here? Or explain in a bit more detail why materializing in a different buffer is a problem?


More information about the llvm-commits mailing list