[LLVMdev] EQTDDataStructures omits obvious, direct callee from DSCallGraph
Ben Liblit
liblit at cs.wisc.edu
Thu Aug 11 08:24:12 PDT 2011
Will Dietz wrote:
> DSA handles indirect and direct callsites differently, and for direct callsites it's expected that the user
> simply looks at the function itself to determine what is called.
>
> In this example, we only track one callsite in test() since as far as
> alias analysis goes, the effects of both callsites are same
OK, that definitely makes sense, including why one direct call site
gives the expected singleton set while the other gives the empty set.
Thank you (and Andrew!) for the clarification.
> That said, we probably could more cleanly export this information to
> the user, but for now just handle direct calls yourself.
I'd humbly suggest that one of the following changes be applied:
(1) Change DSCallGraph::callee_begin() to recognize when its argument is
a direct call site, and return an iterator over a singleton set in that
situation. This has the advantage of subsuming the direct-call check
that many clients of this class might otherwise need to perform
themselves. As an alternative, lazily add direct call sites (and their
singleton callee sets) to ActualCallees on demand whenever such a site
is passed as an argument to DSCallGraph::callee_begin().
(2) Change DSCallGraph::callee_begin() to fail an assertion when its
argument is a direct call site. At least this provides some safety net
to help clients (like me!) who do not realize that DSCallGraph does not
claim to track direct calls reliably.
(3) If fix (1) is not used, then document this
direct-calls-are-not-tracked-reliably restriction *somewhere*. I'm not
sure where exactly, since "poolalloc/dsa-manual/manual.tex" does not
mention DSCallGraph at all. At least it could be put into the
"DSCallGraph.h" header as a comment somewhere.
Regards,
Ben
More information about the llvm-dev
mailing list