[Mlir-commits] [mlir] [mlir][linalg] Restrict linalg.pack to not have artificial padding. (PR #149624)

[Han-Chung Wang]

================
@@ -263,6 +309,24 @@ struct FoldUnpackWithExtractSliceOp
           sliceOp, "expects offsets to be 0s and strides to be 1s");
     }
 
+    // Folding is not allowed if any tile is dropped.
+    RankedTensorType unpackedType = sliceOp.getResultType();
+    SmallVector<int64_t> outerShapeWithoutTranspose =
+        getPackedOuterShapeWithoutTransposition(unpackOp);
+    for (auto [pos, tileSize] : llvm::zip_equal(
+             unpackOp.getInnerDimsPos(), unpackOp.getStaticInnerTiles())) {
+      if (unpackedType.isDynamicDim(pos))
+        return failure();
+      if (ShapedType::isDynamic(outerShapeWithoutTranspose[pos]))
+        return failure();
+      if (ShapedType::isDynamic(tileSize))
+        return failure();
+      int64_t paddingSize = outerShapeWithoutTranspose[pos] * tileSize -
+                            unpackedType.getDimSize(pos);
+      if (paddingSize >= tileSize)
+        return failure();
+    }
----------------
hanhanW wrote:

I just found that we have a similar pattern in canonicalization that needs to be updated. I reviewed the code and thought that it's a canonical form. https://github.com/llvm/llvm-project/commit/1407f5bee9aa8e2a8a4fcab63ab0a3030a8b0dcf

However, now I'm thinking to remove them from canonicalization patterns and people can just build the pass using the pattern if they need the folding. The reason is that `extract_slice` ops are sensitive in tiling concept. They are usually the start point of fusion for TileAndFuse drivers.

The folding here looks more like a graph level cleanup and you maybe want to isolate it a bit from local kernel codegen. It provides more flexibility about how people use the pattern. @Max191 @egebeysel given that you looked at the folding before, WDYT?

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