[LLVMdev] call graph not complete
John McCall
rjmccall at apple.com
Thu Jan 21 11:20:22 PST 2010
On Jan 21, 2010, at 11:03 AM, Sanjiv Gupta wrote:
> 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();
>
> ?
C99 doesn't tell us to generate an indirect call, but it does tell us that we can't make assumptions about the actual signature of foo (other than the return type). That matters here because it means we have no idea what that signature is when we're generating code for main(). You could easily write:
void foo();
int main() {
foo();
}
void foo(int i) {
}
If we codegenned this as a direct call, we'd get:
define i32 @main() nounwind {
entry:
call void (...)* @foo()
ret i32 0
}
define void @foo(i32) nounwind {
entry:
ret void
}
This is a type error, because @foo is not of type void (...)*.
We could work around this specific problem by delaying code-generation for @main until we see the definition of foo, but that still wouldn't work for e.g. link-time optimization.
John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100121/1788b621/attachment.html>
More information about the llvm-dev
mailing list