[llvm] [VPlan] Consider address computation cost in VPInterleaveRecipe. (PR #148808)

[Mel Chen via llvm-commits]

Mel-Chen 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.

> As for making the change in `getInterleavedMemoryOpCost`, I'm happy to move it there if others agree, but it seems that most uses of `getAddressComputationCost` are in LoopVectorize (e.g. [`getUniformMemOpCost`](https://github.com/llvm/llvm-project/blob/900d20d0dc7b228cba9df98ed3ec713098c79342/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp#L5351), [`getGatherScatterCost`](https://github.com/llvm/llvm-project/blob/900d20d0dc7b228cba9df98ed3ec713098c79342/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp#L5381), and [`getMemoryInstructionCost`](https://github.com/llvm/llvm-project/blob/900d20d0dc7b228cba9df98ed3ec713098c79342/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp#L5620)) and VPlanRecipes ([`VPWidenMemoryRecipe::computeCost`](https://github.com/llvm/llvm-project/blob/900d20d0dc7b228cba9df98ed3ec713098c79342/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp#L3102)). What do you think?

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?
But how does this relate to #106431 you mentioned in description? #106431 doesn’t seem to modify anything related to the cost model.


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