[llvm] [VPlan] Model address separately. (PR #72164)

[via llvm-commits]

================
@@ -8174,13 +8174,22 @@ VPRecipeBase *VPRecipeBuilder::tryToWidenMemory(Instruction *I,
   bool Consecutive =
       Reverse || Decision == LoopVectorizationCostModel::CM_Widen;
 
+  VPValue *Ptr = isa<LoadInst>(I) ? Operands[0] : Operands[1];
+  if (Decision != LoopVectorizationCostModel::CM_GatherScatter &&
+      Decision != LoopVectorizationCostModel::CM_Interleave) {
+    auto *VectorPtr = new VPInstruction(
----------------
ayalz wrote:

Note that tryToWiden*() methods typically return one recipe for the given Instruction `I` (or none), also aligning with VPlan evolution roadmap, which is then placed inside the VPBB and set to correspond to `I`. Here two recipes are being introduced, the first placed at the end of Builder's insert block.
Perhaps a single recipe can continue to be returned (possibly abstract w/o an execute()), and later augmented by introducing a complementary recipe or broken it into two recipes, in a VPlan-to-VPlan transform.

Similar to the premature optimization behind VPRecipeOrVPValueTy which should be cleaned up.

Note that `VectorPtr` may be confusing -- it's a scalar pointer used by a vector load or store, as opposed to `Ptr` which may otherwise be a vector of pointers feeding a gather/scatter. But better keep names consistent in this refactoring patch.

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