[llvm-branch-commits] [mlir] [mlir][linalg] Enable scalable vectorization of linalg.unpack (PR #149293)

[Andrzej Warzyński via llvm-branch-commits]

================
@@ -1860,25 +1866,54 @@ vectorizeAsTensorUnpackOp(RewriterBase &rewriter, linalg::UnPackOp unpackOp,
 
   auto destSize = unpackOp.getDestRank();
 
-  if (!inputVectorSizes.empty())
-    assert(inputVectorSizes.size() == destSize &&
+  if (!inputVectorSizes.empty()) {
+    assert(inputVectorSizes.size() == destSize + sourceShape.size() &&
            "Incorrect number of input vector sizes");
+  }
+
+  SmallVector<bool> readScalableVectorFlags;
+  SmallVector<bool> writeScalableVectorFlags;
+  SmallVector<int64_t> readVectorSizes;
+  SmallVector<int64_t> writeVectorSizes;
 
-  // vectorSizes is the shape of the vector that will be used to do final
+  // Split input-vector-sizes into vector sizes for the read and write
+  // operations.
+  if (!inputVectorSizes.empty()) {
----------------
banach-space wrote:

Thanks for these questions!

> even if we have fully static sizes and inner tiles, if the user specifies some size, we use that one

If a "user" provides the configuration, the compiler ought to respect that. Otherwise, we could have a situation where a user provides some input and that's unexpectedly ignored by the compiler. (*)

Also, if a "user" provides the configuration, it is similar to saying "Hey, compiler, I know better, follow my instructions! And ignore the static loop bounds that you may have access to - like I said - I know better." :)

Note that:
* If the user-specified vectors are too large, masking is used to make sure there are no out-of-bounds accesses.
* If the user-specified vectors are smaller than the actual run-time input then there won't be any out-of-bounds accesses anyway.

Hopefully this makes sense :)

> should we maybe add some sort of sanity check for this?

Yes, I have updated the pre-condition calculation in [this commit](https://github.com/llvm/llvm-project/pull/149293/commits/3b482fcb0013d971aa5befb9b99da166a34bb1a5). Can we do more and/or better? 🤔 

(*) One option would be for the compiler to issue some diagnostic saying that the user input was ignored. However, I personally feel that we should avoid such high-level complexities.

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