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().
Any clues?
--
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090930/4cebbf5a/attachment.html>
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090930/5610832a/attachment.html>
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