[llvm] [ArgPromotion] Handle pointer arguments of recursive calls (PR #78735)

[Vedant Paranjape via llvm-commits]

================
@@ -610,15 +614,80 @@ static bool findArgParts(Argument *Arg, const DataLayout &DL, AAResults &AAR,
       // unknown users
     }
 
+    auto *CB = dyn_cast<CallBase>(V);
+    Value *PtrArg = cast<Value>(U);
+    if (IsRecursive && CB && PtrArg) {
+      Type *PtrTy = PtrArg->getType();
+      APInt Offset(DL.getIndexTypeSizeInBits(PtrTy), 0);
+      PtrArg = PtrArg->stripAndAccumulateConstantOffsets(
+          DL, Offset,
+          /* AllowNonInbounds= */ true);
+      if (PtrArg != Arg)
+        return false;
+
+      if (Offset.getSignificantBits() >= 64)
+        return false;
+
+      // If this is a recursive function and one of the argument types is a
+      // pointer that isn't loaded to a non pointer type, it can lead to
+      // recursive promotion. Look for any Load candidates above the function
+      // call that load a non pointer type from this argument pointer. If we
+      // don't find even one such use, return false. For reference, you can
+      // refer to Transforms/ArgumentPromotion/pr42028-recursion.ll and
+      // Transforms/ArgumentPromotion/2008-09-08-CGUpdateSelfEdge.ll
+      // testcases.
+      bool doesPointerResolve = false;
+      for (auto Load : Loads)
+        if (Load->getPointerOperand() == PtrArg &&
+            !Load->getType()->isPointerTy())
+          doesPointerResolve = true;
+
+      if (!doesPointerResolve)
+        return false;
+
+      int64_t Off = Offset.getSExtValue();
+      if (Off)
+        LLVM_DEBUG(dbgs() << "ArgPromotion of " << *Arg << " failed: "
+                          << "pointer offset is not equal to zero\n");
----------------
vedantparanjape-amd wrote:

> Also, you need to implement the check that the argument number matches

Sorry I don't get this. I am doing that check above on L632 already. I am checking if the Use of the said argument matches the argument. So for a recursive call this will be true, no ? I can think of a case like this, in this case there will be two uses of ptr %a if I am not wrong, so the handler will be called twice anyways!

```c
def fun(ptr %a, ptr %b) {
    ...
    ...
    call @func(ptr %a, ptr %a)
    ...
}
```

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