[llvm] [ArgPromotion] Handle pointer arguments of recursive calls (PR #78735)
Vedant Paranjape via llvm-commits
llvm-commits at lists.llvm.org
Wed Jun 12 12:05:02 PDT 2024
================
@@ -422,13 +422,16 @@ doPromotion(Function *F, FunctionAnalysisManager &FAM,
/// Return true if we can prove that all callees pass in a valid pointer for the
/// specified function argument.
-static bool allCallersPassValidPointerForArgument(Argument *Arg,
- Align NeededAlign,
- uint64_t NeededDerefBytes) {
+static bool allCallersPassValidPointerForArgument(
+ Argument *Arg, SmallPtrSet<CallBase *, 4> &RecursiveCalls,
+ Align NeededAlign, uint64_t NeededDerefBytes) {
Function *Callee = Arg->getParent();
const DataLayout &DL = Callee->getParent()->getDataLayout();
APInt Bytes(64, NeededDerefBytes);
+ if (RecursiveCalls.size())
+ return true;
----------------
vedantparanjape-amd wrote:
> > Do, you suggest I add the !dereferenceable metadata to this and run the testcase ?
>
> I was thinking a dereferenceable attribute, not metadata. But yes, that probably makes sense.
```
define internal i32 @foo(ptr dereferenceable(16) %x, i32 %n, i32 %m) {
entry:
%tmp = icmp ne i32 %n, 0
br i1 %tmp, label %cond_true, label %cond_false
cond_true: ; preds = %entry
%tmp2 = load i32, ptr %x, align 4
br label %return
cond_false: ; preds = %entry
%tmp5 = load i32, ptr %x, align 4
%tmp7 = sub i32 %n, 1
%tmp9 = call i32 @foo(ptr %x, i32 %tmp7, i32 %tmp5)
%tmp11 = sub i32 %n, 2
%tmp14 = call i32 @foo(ptr %x, i32 %tmp11, i32 %m)
%tmp15 = add i32 %tmp9, %tmp14
br label %return
cond_next: ; No predecessors!
br label %return
return: ; preds = %cond_next, %cond_false, %cond_true
%retval.0 = phi i32 [ %tmp2, %cond_true ], [ %tmp15, %cond_false ], [ undef, %cond_next ]
ret i32 %retval.0
}
define i32 @bar(ptr %x, i32 %n, i32 %m) {
entry:
%load0 = load i32, ptr %x, align 4
%tmp3 = call i32 @foo(ptr %x, i32 %n, i32 %m)
br label %return
return: ; preds = %entry
ret i32 %tmp3
}
```
I tried something like this, doesn't seem to work either! Can you take a look what might be wrong ?
> > can this be a part of a separate patch
>
> Sure.
https://github.com/llvm/llvm-project/pull/78735
More information about the llvm-commits
mailing list