Hi all,
I have been trying to build a loop nesting analysis which works
interprocedurally. In order
to find the functions called inside a given loop, I am traversing the
Instructions into the
BasicBlock's that conform a Loop, and applying the code that CallGraph
construction uses:
------ extract from CallGraph.cpp : 144
// Look for calls by this function.
for (Function::iterator BB = F->begin(), BBE = F->end(); BB != BBE; ++BB)
for (BasicBlock::iterator II = BB->begin(), IE = BB->end();
II != IE; ++II) {
CallSite CS(cast<Value>(II));
if (CS && !isa<DbgInfoIntrinsic>(II)) {
const Function *Callee = CS.getCalledFunction();
if (Callee)
Node->addCalledFunction(CS, getOrInsertFunction(Callee));
else
Node->addCalledFunction(CS, CallsExternalNode);
}
}
------
While analyzing the IS NAS Parallel Benchmark I find the following BasicBlock:
; <label>:24 ; preds = %20
%25 = call double (...)* bitcast (double (double*, double*)* @randlc to double
(...)*)(double* %t1, double* %t1)
store double %25, double* %t2, align 8
br label %26
As can be seen, the first Instruction after the label contains a call to
randlc(). However, this gets counted by CallGraph as an external node, since
@randlc has been bitcasted and CS.getCalledFunction() fails to return a non-null
value. As a result, the CallGraph for the caller does not contain
randlc(), but a call to an external node instead.
Furthermore, this behavior stems from the following definition of the function
randlc() :
-----
double randlc( X, A ) /* Instead of randlc( double * X, double * A ) */
double * X;
double * A;
{
...
}
-----
If defined with the types included in the header line, the generated call code
does not include a bitcast of the function signature
(although both versions of the code define randlc() using define double
@randlc(double* %X, double* %A) nounwind ).
Summarizing, I have two questions: 1) is the CallGraph analysis "working as
intended" here?; and 2) what would be the correct approach
to modifying the proposed analysis in order to detect that randlc() is being
called in that CallInst ?
Best regards,
Gabriel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110329/9a303aee/attachment.html>
Hi Gabriel, ...> Summarizing, I have two questions: 1) is the CallGraph analysis "working as > intended" here?; and 2) what would be the correct approach > to modifying the proposed analysis in order to detect that randlc() is being > called in that CallInst ?the reason that the callgraph analysis does not try to understand indirect calls like this is that other passes are supposed to sort such things out if they can be sorted out. If they failed then there is no point in having the callgraph analysis try too. The main place that tries to sort out such bitcasts is transformConstExprCastCall in InstCombineCalls.cpp. You may want to rummage around in there to work out why it thinks removing the bitcast is unsafe. So the answers to your questions are: (1) yes, and (2) it is not a job for the analysis - instcombine is the place to take care of this. Ciao, Duncan.
I see, thanks Duncan. The problem was, I was not running the InstCombiner in the first place. Best, Gabriel De: "Duncan Sands" <baldrick at free.fr> Para: llvmdev at cs.uiuc.edu Enviados: Martes, 29 de Marzo 2011 16:47:29 Asunto: Re: [LLVMdev] Anomaly with CallGraph construction Hi Gabriel, ...> Summarizing, I have two questions: 1) is the CallGraph analysis "working as > intended" here?; and 2) what would be the correct approach > to modifying the proposed analysis in order to detect that randlc() is being > called in that CallInst ?the reason that the callgraph analysis does not try to understand indirect calls like this is that other passes are supposed to sort such things out if they can be sorted out. If they failed then there is no point in having the callgraph analysis try too. The main place that tries to sort out such bitcasts is transformConstExprCastCall in InstCombineCalls.cpp. You may want to rummage around in there to work out why it thinks removing the bitcast is unsafe. So the answers to your questions are: (1) yes, and (2) it is not a job for the analysis - instcombine is the place to take care of this. Ciao, Duncan. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110329/1bf96d49/attachment.html>