[llvm] [VPlan] Explicitly handle scalar pointer inductions. (PR #83068)

[via llvm-commits]

================
@@ -270,10 +271,47 @@ VPInstruction::VPInstruction(unsigned Opcode,
   assert(isFPMathOp() && "this op can't take fast-math flags");
 }
 
-Value *VPInstruction::generateInstruction(VPTransformState &State,
-                                          unsigned Part) {
+bool VPInstruction::doesGeneratePerAllLanes() const {
+  return Opcode == VPInstruction::PtrAdd && !vputils::onlyFirstLaneUsed(this);
+}
+
+bool VPInstruction::canGenerateScalarForFirstLane() const {
+  if (Instruction::isBinaryOp(getOpcode()))
+    return true;
+
+  switch (Opcode) {
+  case VPInstruction::BranchOnCond:
+  case VPInstruction::BranchOnCount:
+  case VPInstruction::CalculateTripCountMinusVF:
+  case VPInstruction::CanonicalIVIncrementForPart:
+  case VPInstruction::ComputeReductionResult:
+  case VPInstruction::PtrAdd:
+    return true;
+  default:
+    return false;
+  }
+}
+
+Value *VPInstruction::generatePerLane(VPTransformState &State,
+                                      const VPIteration &Lane) {
+  IRBuilderBase &Builder = State.Builder;
+
+  switch (getOpcode()) {
+  case VPInstruction::PtrAdd: {
+    auto *P = Builder.CreatePtrAdd(State.get(getOperand(0), Lane),
+                                   State.get(getOperand(1), Lane), Name);
+    return P;
+  }
+  default: {
+    Value *Res = generatePerPart(State, Lane.Part);
----------------
ayalz wrote:

Ah, this raises an eyebrow, or two.
When/is it hard for the caller to accurately call for generatePerLane, rather than generatePerPart? The if the former is caller for all lanes, this may end up generating VF copies per same part. Could some assert guard against this from happening, e.g., Lane must be zero?

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