[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