[mlir][bufferization][NFC] Rename copy_tensor op to materialize_in_destination

[matthias-springer]

The previous name was badly chosen. The op is used to ensure that a computation materializes in the future buffer of a certain tensor.

Depends On #65766. Only review the top commit.

[maerhart]

Do I understand correctly that this is not just renaming but also relaxing the guarantees the op provides (guaranteed to lower to a memcpy vs only lowers to a memcpy if needed)?
I assume there are no users of this op that relied on the guarantee of it to lower to a memcpy?

[maerhart]

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?

[matthias-springer]

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.).

[maerhart]

Thanks! That helped understanding a lot. Should we add it to the docs as well?

[matthias-springer]

Do I understand correctly that this is not just renaming but also relaxing the guarantees the op provides (guaranteed to lower to a memcpy vs only lowers to a memcpy if needed)? I assume there are no users of this op that relied on the guarantee of it to lower to a memcpy?

The op still bufferizes to a memref.memcpy, but transformations such as "empty tensor elimination" may remove the op before the bufferization pass is run. That's why I removed the guaranteed part from the description; that's not the point of the op. We don't really care whether there is a memcpy or not. We just want to make sure that the result is in a certain buffer.