================
@@ -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
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
