Consider C code
void foo();
int main(void) {
foo();
return 0;
}
void foo(void) {
int a =10;
}
Bitcode generated by clang with -O0 is :
define i32 @main() nounwind {
entry:
%retval = alloca i32 ; <i32*> [#uses=3]
store i32 0, i32* %retval
call void (...)* bitcast (void ()* @foo to void (...)*)()
store i32 0, i32* %retval
%0 = load i32* %retval ; <i32> [#uses=1]
ret i32 %0
}
define void @foo() nounwind {
entry:
%a = alloca i32, align 4 ; <i32*> [#uses=1]
store i32 10, i32* %a
ret void
}
Bitcode generated by llvm-ld with -disable-opt and -basiccg options is:
define i32 @main() nounwind {
entry:
%retval = alloca i32 ; <i32*> [#uses=3]
store i32 0, i32* %retval
call void (...)* bitcast (void ()* @foo to void (...)*)()
store i32 0, i32* %retval
%0 = load i32* %retval ; <i32> [#uses=1]
ret i32 %0
}
define void @foo() nounwind {
entry:
%a = alloca i32, align 4 ; <i32*> [#uses=1]
store i32 10, i32* %a
ret void
}
My point is why is the call to foo not resolved correctly in llvm-ld.
Here if I try to make use of the call graph pass to get the call graph,
I do not get the complete call graph.
Thanks
Vasudev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100120/cc2eb964/attachment.html>
Hi,> Bitcode generated by llvm-ld with –disable-opt and –basiccg options is:...> My point is why is the call to foo not resolved correctly in llvm-ld.Resolving an call to a direct call is an optimization. But you turned all optimizations off. Ciao, Duncan.
Duncan Sands wrote:> Hi, > > >> Bitcode generated by llvm-ld with –disable-opt and –basiccg options is: >> > > ... > > > >> My point is why is the call to foo not resolved correctly in llvm-ld. >> > > Resolving an call to a direct call is an optimization. But you turned all > optimizations off. >How can we just selectively turn only that optimization ON? We don't want to turn on a whole lot of other stuff that instcombine does as they mess up debugging in our case. - Sanjiv> Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Duncan Sands wrote:> Hi, > > >> Bitcode generated by llvm-ld with –disable-opt and –basiccg options is: >> > > ... > > > >> My point is why is the call to foo not resolved correctly in llvm-ld. >> > > Resolving an call to a direct call is an optimization. But you turned all > optimizations off. > >BTW, why do clang generates an indirect call in the first place for the program given in the original post? Does c99 tell us to generate an indirect call when the prototype is like this void foo(); ? - Sanjiv> Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Duncan Sands wrote:> Hi, > > >> Bitcode generated by llvm-ld with –disable-opt and –basiccg options is: >> > > ... > > > >> My point is why is the call to foo not resolved correctly in llvm-ld. >> > > Resolving an call to a direct call is an optimization. But you turned all > optimizations off. > > Ciao, > > Duncan. > > Resolving an call to a direct call is an optimization. But you turned all > optimizations off. > > Ciao, > > Duncan. >Shouldn't the call resolution be part of call graph analysis? - Sanjiv> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >