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...