[llvm] [Attributor] Don't specialize an indirect call for a callee that reaches it (PR #217079)

Larry Meadows via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 19 03:10:53 PDT 2026


================
@@ -12495,11 +12495,51 @@ struct AAIndirectCallInfoCallSite : public AAIndirectCallInfo {
       AllCalleesKnownNow = false;
     }
 
+    // A direct call to a callee that can reach the function holding this call
+    // site closes a call graph cycle that previously existed only through the
+    // function pointer, and nothing downstream undoes that: an alwaysinline
+    // dispatcher stops being inlinable once it is in a cycle, and on a target
+    // without a dynamically sized stack the recursion it leaves behind has no
+    // statically known stack size. Record which callees those are so manifest()
+    // can leave them to the indirect call. The question has to be asked here,
+    // because the solver no longer answers once manifestation starts.
+    //
+    // Only edges the call graph agrees are direct can close such a cycle, so
+    // walk the solver's known edges rather than asking AAInterFnReachability,
+    // which conservatively reaches everything downstream of an unknown callee
+    // and would suppress far more than this.
----------------
lfmeadow wrote:

Right, thanks — the walk does follow `getOptimisticEdges()`, which carries the callees AACallEdges models for indirect calls, so "edges the call graph agrees are direct" misdescribes them. The distinction I was drawing is against `AAInterFnReachability`, which reaches everything downstream of an *unknown* callee; the point is resolved-to-a-particular-function, not direct.

Reworded. The behaviour is unchanged, and including those modelled edges is the conservative direction here: it can only find more cycles and leave more callees to the indirect call.


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


More information about the llvm-commits mailing list