[llvm] [VPlan] Consider address computation cost in VPInterleaveRecipe. (PR #148808)
Ricardo Jesus via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 11 07:25:53 PDT 2025
rj-jesus wrote:
> > Or are you suggesting a more complex test, similar to the loop in the PR description (https://godbolt.org/z/o1fGfj6j7)?
>
> If a simple example is enough to demonstrate the cost model issue for factor 5, then a simple example should be sufficient.
I think a simple test, like those in `Transforms/LoopVectorize/AArch64/interleaved_cost.ll`, won't show a lot more than what the tests already in the file show. I'll put together a more complete example, based on the loop in the description.
> The issue here seems to be that originally the cost model behaved as expected — keeping it scalar — but at some point, the cost model started to think interleaving was more profitable, right?
Yes, exactly.
> But how does this relate to #106431 you mentioned in description? #106431 doesn’t seem to modify anything related to the cost model.
It doesn't modify the cost model per se, but it removes an instruction from the recipe that nudges the cost model to prefer interleaving. Before #106431 we have:
```
Cost of 1 for VF 2: CLONE ir<%12> = add nuw nsw vp<%5>, ir<4>
...
Cost of 0 for VF 2: CLONE ir<%arrayidx34> = getelementptr inbounds ir<%a>, ir<%12>
...
Cost of 28 for VF 2: INTERLEAVE-GROUP with factor 5 at <badref>, ir<%arrayidx34>
```
After, the first two instructions are removed and we have:
```
Cost of 28 for VF 2: INTERLEAVE-GROUP with factor 5 at <badref>, ir<%arrayidx3>
```
https://github.com/llvm/llvm-project/pull/148808
More information about the llvm-commits
mailing list