[llvm] [FuncAttrs] Relax norecurse attribute inference (PR #139943)
Usha Gupta via llvm-commits
llvm-commits at lists.llvm.org
Mon Jul 7 04:26:20 PDT 2025
================
@@ -2322,8 +2343,39 @@ PreservedAnalyses PostOrderFunctionAttrsPass::run(LazyCallGraph::SCC &C,
Functions.push_back(&N.getFunction());
}
- auto ChangedFunctions =
- deriveAttrsInPostOrder(Functions, AARGetter, ArgAttrsOnly);
+ bool NoFunctionsAddressIsTaken = false;
+ // Check if any function in the whole program has its address taken or has
+ // potentially external linkage.
+ // We use this information when inferring norecurse attribute: If there is
+ // no function whose address is taken and all functions have internal
+ // linkage, there is no path for a callback to any user function.
+ if (IsLTOPostLink || ForceLTOFuncAttrs) {
+ bool AnyFunctionsAddressIsTaken = false;
+ // Get the parent Module of the Function
+ Module &M = *C.begin()->getFunction().getParent();
+ for (Function &F : M) {
+ // We only care about functions defined in user program whose addresses
+ // escape, making them potential callback targets.
+ if (F.isDeclaration())
+ continue;
+
+ // If the function is already marked as norecurse, this should not block
+ // norecurse inference even though it may have external linkage.
+ // For ex: main() in C++.
+ if (F.doesNotRecurse())
+ continue;
----------------
usha1830 wrote:
> Is it possible that the definition of norecurse in the LangRef refers to the call graph, which would simply show that foo() calls a(), which calls bar(), which could call foo()? In this definition adding norecurse to foo would be incorrect.
@david-arm This is my current understanding about `norecurse `and I think it should be incorrect to add `norecurse `to `foo`.
Like you said, to infer `norecurse `on `foo `will need lot more information about the callee `a `( that it conditionally calls external function and is called with an argument which fails that condition in the callee). It would get a lot more complex. :(
https://github.com/llvm/llvm-project/pull/139943
More information about the llvm-commits
mailing list