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

[David Sherwood via llvm-commits]

================
@@ -3666,6 +3666,9 @@ InstructionCost VPInterleaveRecipe::computeCost(ElementCount VF,
       InsertPos->getOpcode(), WideVecTy, IG->getFactor(), Indices,
       IG->getAlign(), AS, Ctx.CostKind, getMask(), NeedsMaskForGaps);
 
+  // Add the address computation cost.
+  Cost += Ctx.TTI.getAddressComputationCost(WideVecTy);
----------------
david-arm wrote:

The main problem that I see here is that there is now an inconsistency between this and `LoopVectorizationCostModel::getInterleaveGroupCost` in the legacy cost model. This is potentially bad for two reasons:

1. It can lead to more asserts firing when the legacy and vplan cost models don't match.
2. In LoopVectorizationCostModel::setCostBasedWideningDecision we choose the best widening decision based on a comparison between interleaving, gather/scatter or scalar. If we just change VPInterleaveRecipe::computeCost then we only get the benefit of choosing a better interleave count/unroll factor, but the best decision may simply be to scalarise.

It might be good to see what happens if you add the same cost to LoopVectorizationCostModel::getInterleaveGroupCost?

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