search for: actualcallee

...tLowering.cpp +++ b/lib/CodeGen/SelectionDAG/StatepointLowering.cpp @@ -238,6 +238,9 @@ static SDNode *lowerCallFromStatepoint(const CallInst &CI, // differently. Hopefully, this is slightly more robust w.r.t. calling // convention, return values, and other function attributes. Value *ActualCallee = const_cast<Value *>(StatepointOperands.actualCallee()); + FunctionType *FTy = + cast<FunctionType>(cast<PointerType>(ActualCallee->getType())->getElementType()); + bool isVarArg = FTy->isVarArg(); std::vector<Value *> Args; CallInst::const_op_iterator...

...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 direct call but a correct singleton set for the other direct call is a troubling inconsistency that leaves me unsure which results I ca...

...o 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 direct call but a correct singleton > set for the other direct call is a troubling inconsistency that leaves > me unsur...

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

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,

...?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 direct call but a correct singleton >> set for the other direct call is a troubling inconsistency that leaves &...