[LLVMdev] Internalize pass

[Talin]

Well, after some investigation I have a few more clues as to what is 
going on.

I have a module which contains a call to an external native function. 
This native function lives in a static library, and there is an external 
declaration for it in the module.

I find that I can run "llvm-ld -disable-opts -native -l mylibrary 
test.bc" and it works fine. That is, llvm-ld is able to generate a 
native object file, and link it against the static library with no problem.

However, if I remove the "-disable-opts" line, it seems to replace the 
call to the native function with "unreachable". I'm not 100% certain of 
this, but if I replace the native function with a non-native function 
that does something similar, then it seems to work ok.

Chris Lattner wrote:
>
> On Sep 30, 2009, at 12:06 AM, Talin wrote:
>
>> I'm playing around with different combinations of LTO passes, and 
>> I've run into a strange problem:
>>
>> I have a 'main' function that looks like this:
>>
>> define i32 
>> @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"* 
>> %args) {
>> entry:
>>   call void @llvm.dbg.func.start(metadata !0)
>>   call void @llvm.dbg.stoppoint(i32 2, i32 19, metadata !1)
>>   %integerLimitsTest = call { } @integerLimitsTest() ; <{ }> [#uses=0]
>>   call void @llvm.dbg.stoppoint(i32 3, i32 21, metadata !1)
>>   %integerToStringTest = call { } @integerToStringTest() ; <{ }> 
>> [#uses=0]
>>   call void @llvm.dbg.stoppoint(i32 4, i32 9, metadata !1)
>>   call void @llvm.dbg.region.end(metadata !0)
>>   ret i32 0
>> }
>>
>> However, when I add an internalize pass before the other LTO passes, 
>> the 'main' function turns into this:
>>
>> define i32 @main(i32, i8** nocapture) nounwind readnone {
>> entry:
>>   tail call void @llvm.dbg.func.start(metadata !0)
>>   tail call void @llvm.dbg.stoppoint(i32 3, i32 21, metadata !1)
>>   unreachable
>> }
>>
>> The thing is, there's nothing particularly special or interesting 
>> about the functions being called from main().
>
> This is likely to not be due to internalize itself.  Internalize marks 
> functions "internal", which allows other interprocedural optimizers to 
> have more freedom to change their interfaces etc.  The likely problem 
> here is that you are calling something from 'main' with mismatching 
> calling conventions or something like that.  It is hard to say without 
> a full testcase.
>
> -Chris