[llvm] [VPlan] Add VPPhiAccessors to provide interface for phi recipes (NFC) (PR #129388)

[via llvm-commits]

================
@@ -1171,6 +1171,59 @@ class VPIRInstruction : public VPRecipeBase {
   void extractLastLaneOfFirstOperand(VPBuilder &Builder);
 };
 
+/// Helper type to provide functions to access incoming values and blocks for
+/// phi-like recipes. RecipeTy must be a sub-class of VPRecipeBase.
+template <typename RecipeTy> class VPPhiAccessors {
+  /// Return a VPRecipeBase* to the current object.
+  const VPRecipeBase *getAsRecipe() const {
+    return static_cast<const RecipeTy *>(this);
+  }
+
+public:
+  /// Returns the incoming VPValue with index \p Idx.
+  VPValue *getIncomingValue(unsigned Idx) const {
+    return getAsRecipe()->getOperand(Idx);
+  }
----------------
ayalz wrote:

OK, who are all the relevant classes - expected to inherit directly from `VPPhiAccessors` in addition to `VPWidenPHIRecipe` (who could use `VPSingleDefPhiRecipe` with other potential partners) and `VPIRPhi`?

If `VPIRPhi` inherits directly from `VPPhiAccessors`, could it implement getIncomingBlock based on the direct predecessors of its VPBasicBlock, as it is not used to represent header phi's of HCFG regions? I.e., assert it has direct predecessors.

In any case, good to implement both `getIncomingBlock` and `getIncomingValue` by the mix-in, as done here, or neither (and have both defined by all derived classes instead).

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