================ ---------------- mmjjpp wrote:
> I'm a little unsure of how you are detecting indirect calls below. The indirect-call detection currently uses two complementary approaches: Tracing uses of address-taken functions: for each function whose address is taken, we recursively traverse its users (including constants and global variables). When an instruction using the function pointer is found, we attribute that indirect-call relationship to the instruction’s parent function. Resolving indirect call instructions: for call instructions whose callee cannot be resolved directly, we: strip pointer casts to recover the underlying function where possible; consult callees metadata; use indirect-call PGO profile data to add the profiled candidate callees. > what do you mean by "non-entrypoint" function? By “non-entrypoint function,” I mean a function that is not a root of the simplified call graph. We identify graph roots by checking NumReferences == 0, where NumReferences is the number of incoming edges. This is a graph-level notion and does not necessarily mean the program’s actual entry function. For example, in a strongly connected component such as A -> B -> A, both functions have incoming references, so neither has NumReferences == 0. Such functions are therefore not discovered through the initial root search; the implementation handles these unvisited cyclic components afterward by treating one of their functions as a root. https://github.com/llvm/llvm-project/pull/198702 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
