[Mlir-commits] [mlir] [mlir][VectorOps] Add `vector.interleave` operation (PR #80315)

Diego Caballero llvmlistbot at llvm.org
Mon Feb 5 10:21:19 PST 2024


================
@@ -6308,6 +6308,48 @@ bool WarpExecuteOnLane0Op::areTypesCompatible(Type lhs, Type rhs) {
       verifyDistributedType(lhs, rhs, getWarpSize(), getOperation()));
 }
 
+//===----------------------------------------------------------------------===//
+// InterleaveOp
+//===----------------------------------------------------------------------===//
+
+// The rank 1 case of vector.interleave on fixed-size vectors is equivalent to a
+// vector.shuffle, which (as an older op) is more likely to be matched by
+// existing pipelines.
+struct FoldRank1FixedSizeInterleaveOp : public OpRewritePattern<InterleaveOp> {
----------------
dcaballe wrote:

It should be ok to change an existing canonical representation if the new one is more explicit for a particular case.

> I don't think vector.interleave provides any more information in the case either, once you've matched the shuffle mask

Well, that's exactly the point! Some of the ops we have at this level are intended to simplify the analysis part of well-defined cases that are commonly used. Analyzing the shuffle mask is doable but it's adding complexity and we would have to exclude the non-interleave cases from the interleave ones when we have rewrites only targeting the interleave ones. 

> I would not be surprised if adding a vector.shuffle -> vector.interleave canonicalization broke something somewhere (maybe in a downstream project).

It's possible but `vector.shuffle` is used very late in the pipeline and we don't have so many rewrites targeting it. I think the benefit of having scalable and non-scalable aligned and more explicit representation for vector interleave patterns is worth the risk.

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


More information about the Mlir-commits mailing list