[Question] Clarify UnPack vector size inference: “multiply then divide” looks like a round-trip

[sakupan102]

Summary

In vector size inference for linalg::UnPackOp, inferSizesFromIR multiplies selected dims by inner tile sizes to reconstruct the write vector width, and then getVectorInputSizesFromDestTiles divides by the same tiles to derive the read vector sizes. While the intent seems to be “write width reconstruction → read width derivation,” the code reads as a multiply-then-divide round-trip and is hard to follow. I’d like to confirm the intent and propose clarity improvements.

Affected Code

multiply (rebuild write vector):
https://github.com/iree-org/iree/blob/main/compiler/src/iree/compiler/Codegen/Utils/Utils.cpp#L1884-L1887
divide (derive read vector):
https://github.com/iree-org/iree/blob/main/compiler/src/iree/compiler/Codegen/Utils/Utils.cpp#L1843-L1846

Questions

• Is it feasible to compute read vector sizes directly (from input/source + tiling/permutation) and skip the multiply-then-divide?

[sakupan102]

@krzysz00 @hanhanW
hope you don’t mind the ping. I saw your work on #21609 and it appears related to the problem I’m facing here.
Any guidance or confirmation would be greatly appreciated. Thanks!

[hanhanW]

I'm the author of those inferences. It's been some time since I touched the code. IIRC, inferSizesFromIR is mainly for the inference in SSA chain. We use the inferSizesFromIR to figure vector shapes in the SSA chain. After you get the vector shapes for some operands, you provide the sizes to vectorizer.

Due to the upstream change, which is also reasonable to me, we have to provide additional sizes for a few more dimensions; the intention is to support scalable vectorization for unpack ops. It is a placeholder for dynamic value analysis. I.e., the redundancy exists when we talk about non-scalable vectorization.

[hanhanW]

getVectorInputSizesFromDestTiles also helps you get vector sizes, if you get the vector sizes from lowering config. The vector size inference is mainly to match the original lowering config, since lowering config can be changed or dropped during transformations, which is fragile. Inference is a better solution to me.

[sakupan102]

@hanhanW
Thank you for answering my question.
So, is this what it comes down to?

• Since the upstream API now requires passing a read vector instead of a write vector, we need logic (getVectorInputSizesFromDestTiles) to compute the read vector from the write vector in order to adapt to that change.
• The upstream change is to support scalable vectors, but getVectorInputSizesFromDestTiles currently can’t handle scalable vectors, so there’s some redundancy: https://github.com/iree-org/iree/pull/21609/files#diff-259fa6ee413b9c1dbac0f3b6ed6618e324b38fd17627492b5f9d4b8b96ab06e4R317

Please let me know if I’ve misunderstood anything.

[hanhanW]

Most context is correct. I think your missing context is the gap of the sizes for tiling and vectorization. We use lowering config in tiling; they represent unpacked domain tile sizes, i.e., dest shape. There are two steps in vectorization:

1. Get the tiling sizes from either IR inference or lowering config.
2. Then we use the sizes to infer the vector sizes. It is true for other ops that the tile sizes from lowering config match vector size, but it is not true for unpack ops. This is why you see the "redundancy".

[sakupan102]

Thanks, that helps—I think I’m getting the picture. My understanding is:

• In inferSizesFromIR, we first compute tiling sizes (the “multiply” step).

• For UnPack, there’s a gap between tile sizes and the vector sizes actually needed for vectorization, so we have getVectorInputSizesFromDestTiles to bridge that gap.

• Today, getVectorInputSizesFromDestTiles is effectively a placeholder for dynamic/scalable analysis, so in the common non-scalable case it ends up dividing the dest tiles (the “divide” step).

Is that the right way to describe why we see the multiply→divide round trip? .

[hanhanW]

Yes, you are correct. Feel free to reach out if you have any other questions. :)