[Mlir-commits] [mlir] [mlir][tensor] Add a tensor.concat operation (PR #72779)

[Quinn Dawkins]

================
@@ -121,6 +121,66 @@ def Tensor_CastOp : Tensor_Op<"cast", [
   let hasCanonicalizer = 1;
 }
 
+//===----------------------------------------------------------------------===//
+// ConcatOp
+//===----------------------------------------------------------------------===//
+
+def Tensor_ConcatOp : Tensor_Op<"concat",
+    [Pure,
+     DeclareOpInterfaceMethods<OpAsmOpInterface, ["getAsmResultNames"]>,
+     DeclareOpInterfaceMethods<ReifyRankedShapedTypeOpInterface>]> {
+  let summary = "tensor concatenation operation";
+  let description = [{
+    The "concat" operation constructs a tensor out of a variadic list of input
+    tensors, concatenated along a static dimension. All inputs and the result
+    type must share the same rank.
+
+    `dim` specifies the dimension along which to concatenate. The size of the
+    concatenated dimension in the result must be equal to the sum of the sizes
+    of the inputs along that dimension. All other dimensions in both the inputs
+    and result must be the same size.
+
+    Example:
+
+    ```mlir
+    %0 = tensor.concat dim(0) %0, %1, %2 :
----------------
qedawkins wrote:

> I've been thinking of extending bufferization.materialize_in_destination with a region that can wrap a single arbitrary non-DPS op and provide the missing destination.

If this is a future possibility then non-DPS sounds good to me. It is more consistent with other dialects and is easier to work with at higher levels (why I have it as non-DPS now).

> Regarding memref.concat: I would just generate memref.subview+memref.copy directly to keep the memref dialect as simple as possible. (Unless you want to do tiling of memref IR.)

Probably not? I don't know what others would end up wanting to do, but keeping memref simple makes sense. I'll let someone else make the case for it if they think they need it, I was mainly trying to think of reasons for the choice in this op.

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