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
Sounds like LLVM thinks the calling conventions or declarations are mismatched. See: http://llvm.org/docs/FAQ.html#callconvwrong Reid On Sat, Oct 3, 2009 at 1:16 AM, Talin <viridia at gmail.com> wrote:> 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Reid Kleckner wrote:> Sounds like LLVM thinks the calling conventions or declarations are > mismatched. See: > http://llvm.org/docs/FAQ.html#callconvwrong > >BTW, I'm still completely stumped on this issue, and I've put it aside to work on other things. But it would be nice to re-enable internalize :)> Reid > > On Sat, Oct 3, 2009 at 1:16 AM, Talin <viridia at gmail.com> wrote: > >> 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 >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > >