search for: callee_begin

Displaying 6 results from an estimated 6 matches for "callee_begin".

2011 Aug 10
2
[LLVMdev] EQTDDataStructures omits obvious, direct callee from DSCallGraph
Andrew Lenharth wrote: > If I remember correctly, it only tries to resolve indirect calls. The > analysis doesn't track direct calls because you can do it just as well > yourself. DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to iterate over an empty set (EmptyActual) for any call site not found in the ActualCallees map. So if direct calls are not tracked, then I would expect the callee iterators for *both* direct calls to yield this empty set. Getting the empty set for one di...
2011 Aug 11
0
[LLVMdev] EQTDDataStructures omits obvious, direct callee from DSCallGraph
...2011 at 10:45 PM, Ben Liblit <liblit at cs.wisc.edu> wrote: > Andrew Lenharth wrote: >> If I remember correctly, it only tries to resolve indirect calls.  The >> analysis doesn't track direct calls because you can do it just as well >> yourself. > > DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to > iterate over an empty set (EmptyActual) for any call site not found in > the ActualCallees map.  So if direct calls are not tracked, then I would > expect the callee iterators for *both* direct calls to yield this empty > set.  Getting the...
2011 Aug 09
0
[LLVMdev] EQTDDataStructures omits obvious, direct callee from DSCallGraph
On Tue, Aug 9, 2011 at 6:19 PM, Ben Liblit <liblit at cs.wisc.edu> wrote: > I am using EQTDDataStructures (from the poolalloc project) to resolve > indirect function calls to over-approximated sets of possible callees. If I remember correctly, it only tries to resolve indirect calls. The analysis doesn't track direct calls because you can do it just as well yourself. Andrew
2006 May 22
2
[LLVMdev] Indirect function call
...nd(); ++I) { for(BasicBlock::iterator J = I->begin(); J != I->end(); ++J) { if(CallInst *cs = dyn_cast<CallInst>(J)) { Function *callee = cs->getCalledFunction(); if(callee) continue;//not a function pointer. for(CompleteBUDataStructures::callee_iterator K = DS.callee_begin(J); K != DS.callee_end(J); ++K) { if(K->first != J) continue; CallGraphNode *cgn = getAnalysis<CallGraph>()[f]; // Find a indirect call! CallGraphNode *calleecgn = getAnalysis<CallGraph>()[K->second]; cgn->addCalledFunction(calleecgn); std::cerr&l...
2011 Aug 09
2
[LLVMdev] EQTDDataStructures omits obvious, direct callee from DSCallGraph
I am using EQTDDataStructures (from the poolalloc project) to resolve indirect function calls to over-approximated sets of possible callees. Unfortunately I find that it yields incorrect results even on a very simple test input. My LLVM and poolalloc sources are Subversion trunk checkouts, no more than a day older than the current trunk head. My test input is the following C source,
2011 Aug 11
1
[LLVMdev] EQTDDataStructures omits obvious, direct callee from DSCallGraph
...lit <liblit at cs.wisc.edu> wrote: >> Andrew Lenharth wrote: >>> If I remember correctly, it only tries to resolve indirect calls. ?The >>> analysis doesn't track direct calls because you can do it just as well >>> yourself. >> >> DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to >> iterate over an empty set (EmptyActual) for any call site not found in >> the ActualCallees map. ?So if direct calls are not tracked, then I would >> expect the callee iterators for *both* direct calls to yield this empty >> se...