[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