[Mlir-commits] [mlir] [mlir][VectorOps] Add vector.interleave operation (1/4) (PR #80965)

[Nicolas Vasilache]

================
@@ -478,6 +478,69 @@ def Vector_ShuffleOp :
   let hasCanonicalizer = 1;
 }
 
+def Vector_InterleaveOp :
+  Vector_Op<"interleave", [Pure,
+    AllTypesMatch<["lhs", "rhs"]>,
+    TypesMatchWith<
+    "type of 'result' is double the width of the inputs",
+    "lhs", "result",
+    [{
+      [&]() -> ::mlir::VectorType {
+        auto vectorType = ::llvm::cast<mlir::VectorType>($_self);
+        ::mlir::VectorType::Builder builder(vectorType);
+        if (vectorType.getRank() == 0) {
+          static constexpr int64_t v2xty_shape[] = { 2 };
+          return builder.setShape(v2xty_shape);
+        }
+        auto lastDim = vectorType.getRank() - 1;
+        return builder.setDim(lastDim, vectorType.getDimSize(lastDim) * 2);
+      }()
+    }]>]> {
+  let summary = "constructs a vector by interleaving two input vectors";
+  let description = [{
+    The interleave operation constructs a new vector by interleaving the
+    elements from the trailing (or final) dimension of two input vectors,
+    returning a new vector where the trailing dimension is twice the size.
+
+    Note that for the n-D case this differs from the interleaving possible with
----------------
nicolasvasilache wrote:

Thanks for proposing this, 2 questions come to mind:
1. what is the state of the 1-D support for vector.shuffle / shufflevector in MLIR / LLVM for scalable types? Is this generally supported for various permutations or is interleaving a desirable outlier (because e.g. the HW can really do well on this but not on more general permutations)?
2. would this be necessary if https://github.com/llvm/llvm-project/commit/1fe65688d42d1dacca528a871ac8de370043f793 had introduced shuffles to be on the innermost dim? I can't remember the rationale but shuffling the outer dims is more or less a loop in many cases since these dimensions get unrolled when lowering, on most HW...

I am trying to gauge whether we would be better off having a `vector.shuffle_innermost_dim` that takes a general shuffle mask, for which `vector.interleave` is a special case that is easy to detect.

In the absence of compelling HW reasons to only have interleave, I'd favor a "better shuffle" because it is very easy to detect that `[0, n, 1, n+1 ... n-1, 2n-1]` is an interleave.

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