I have some code generated with llvm-g++ and llvm-link that includes a tail call that is confusing me for two reasons: 1) I am not sure why it is a tail call (i.e. it does not look like it is in the tail position) 2) When I instrument the code using my opt pass, none of the instrumentation functions in the callee get called, leading me to believe that some funny business is going on. Below I have pasted the tail call in question and surrounding code. My instrumentation pass instruments every llvm instruction. When I run it and just print out debug info, I see all the instructions up to the tail call, the tail call instruction itself, and then the icmp following the tail call. But none of the debug info from within the callee gets printed. I do not use "-tailcallopt" as an option for llc when I generate the code. It seems like I am misunderstanding something about tail calls and tail call optimization. Any insight might help me debug this issue. Thanks, Scott define linkonce_odr i64 @_ZN16FCEmailInputFile4openERKSsR11FCIdManager(%struct.FCEmailInputFile* %this, %"struct.std::basic_string<char,std::char_traits<char>,std::allocator<char>>"* nocapture %fn, %struct.FCIdManager* nocapture %idm) align 2 {entry: %0 = getelementptr inbounds %"struct.std::basic_string<char,std::char_traits<char>,std::allocator<char>>"* %fn, i64 0, i32 0, i32 0 ; <i8**> [#uses=1]%1 = load i8** %0, align 8 ; <i8*> [#uses=1] %2 = getelementptr inbounds %struct.FCEmailInputFile* %this, i64 0, i32 1 ; <%"struct.std::ifstream"*> [#uses=1] %3 = getelementptr inbounds %struct.FCEmailInputFile* %this, i64 0, i32 1, i32 1 ; <%"struct.std::basic_filebuf<char,std::char_traits<char> >"*> [#uses=1] %4 = tail call %"struct.std::basic_filebuf<char,std::char_traits<char> >"* @_ZNSt13basic_filebufIcSt11char_traitsIcEE4openEPKcSt13_Ios_Openmode(%"struct.std::basic_filebuf<char,std::char_traits<char>>"* %3, i8* %1, i32 8) ;<%"struct.std::basic_filebuf<char,std::char_traits<char> >"*> [#uses=1] %5 = icmp eq %"struct.std::basic_filebuf<char,std::char_traits<char> >"* %4, null ; <i1> [#uses=1] %6 = getelementptr inbounds %struct.FCEmailInputFile* %this, i64 0, i32 1, i32 0, i32 0 ; <i32 (...)***> [#uses=1] %7 = load i32 (...)*** %6, align 8 ; <i32 (...)**> [#uses=1] %8 = getelementptr inbounds i32 (...)** %7, i64 -3 ; <i32 (...)**> [#uses=1] %9 = bitcast i32 (...)** %8 to i64* ; <i64*> [#uses=1] %10 = load i64* %9, align 8 ; <i64> [#uses=1] %11 = ptrtoint %"struct.std::ifstream"* %2 to i64 ; <i64> [#uses=1] %12 = add i64 %10, %11 ; <i64> [#uses=1] %13 = inttoptr i64 %12 to %"struct.std::basic_ios<char,std::char_traits<char> >"* ; <%"struct.std::basic_ios<char,std::char_traits<char> >"*> [#uses=6] br i1 %5, label %bb.i, label %bb1.i -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100316/7ebc35d9/attachment.html>
On Mar 16, 2010, at 6:46 PM, Scott Ricketts wrote:> I have some code generated with llvm-g++ and llvm-link that includes a tail call that is confusing me for two reasons: > > 1) I am not sure why it is a tail call (i.e. it does not look like it is in the tail position)The "tail" marker has a very specific description in LLVM IR: it says that the caller does not access the callee's stack: http://llvm.org/docs/LangRef.html#i_call> 2) When I instrument the code using my opt pass, none of the instrumentation functions in the callee get called, leading me to believe that some funny business is going on.I don't know about this. -Chris> > Below I have pasted the tail call in question and surrounding code. My instrumentation pass instruments every llvm instruction. When I run it and just print out debug info, I see all the instructions up to the tail call, the tail call instruction itself, and then the icmp following the tail call. But none of the debug info from within the callee gets printed. > > I do not use "-tailcallopt" as an option for llc when I generate the code. > > It seems like I am misunderstanding something about tail calls and tail call optimization. Any insight might help me debug this issue. > > Thanks, > Scott > > define linkonce_odr i64 @_ZN16FCEmailInputFile4openERKSsR11FCIdManager(%struct.FCEmailInputFile* %this, %"struct.std::basic_string<char,std::char_traits<char>,std::allocator<char> >"* nocapture %fn, %struct.FCIdManager* nocapture %idm) align 2 { > entry: > %0 = getelementptr inbounds %"struct.std::basic_string<char,std::char_traits<char>,std::allocator<char> >"* %fn, i64 0, i32 0, i32 0 ; <i8**> [#uses=1] > %1 = load i8** %0, align 8 ; <i8*> [#uses=1] > %2 = getelementptr inbounds %struct.FCEmailInputFile* %this, i64 0, i32 1 ; <%"struct.std::ifstream"*> [#uses=1] > %3 = getelementptr inbounds %struct.FCEmailInputFile* %this, i64 0, i32 1, i32 1 ; <%"struct.std::basic_filebuf<char,std::char_traits<char> >"*> [#uses=1] > %4 = tail call %"struct.std::basic_filebuf<char,std::char_traits<char> >"* @_ZNSt13basic_filebufIcSt11char_traitsIcEE4openEPKcSt13_Ios_Openmode(%"struct.std::basic_filebuf<char,std::char_traits<char> >"* %3, i8* %1, i32 8) ; <%"struct.std::basic_filebuf<char,std::char_traits<char> >"*> [#uses=1] > %5 = icmp eq %"struct.std::basic_filebuf<char,std::char_traits<char> >"* %4, null ; <i1> [#uses=1] > %6 = getelementptr inbounds %struct.FCEmailInputFile* %this, i64 0, i32 1, i32 0, i32 0 ; <i32 (...)***> [#uses=1] > %7 = load i32 (...)*** %6, align 8 ; <i32 (...)**> [#uses=1] > %8 = getelementptr inbounds i32 (...)** %7, i64 -3 ; <i32 (...)**> [#uses=1] > %9 = bitcast i32 (...)** %8 to i64* ; <i64*> [#uses=1] > %10 = load i64* %9, align 8 ; <i64> [#uses=1] > %11 = ptrtoint %"struct.std::ifstream"* %2 to i64 ; <i64> [#uses=1] > %12 = add i64 %10, %11 ; <i64> [#uses=1] > %13 = inttoptr i64 %12 to %"struct.std::basic_ios<char,std::char_traits<char> >"* ; <%"struct.std::basic_ios<char,std::char_traits<char> >"*> [#uses=6] > br i1 %5, label %bb.i, label %bb1.i > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Tue, Mar 16, 2010 at 6:57 PM, Chris Lattner <clattner at apple.com> wrote:> > The "tail" marker has a very specific description in LLVM IR: it says that the caller does not access the callee's stack: > http://llvm.org/docs/LangRef.html#i_callAh that makes more sense. Thanks for the pointer.> > 2) When I instrument the code using my opt pass, none of the instrumentation functions in the callee get called, leading me to believe that some funny business is going on. > I don't know about this.That is because I did not give you enough information :). I realized that the callee was linkonce_odr, and so the function body that I was instrumenting was not making its way into the final executable. This is why I was not seeing my debug info printed. So if I am looking at a CallInst, and want to know if the callee is going to be instrumented by my pass, I can check F->isWeakForLinker(), where F is the called function. But this just tells me when the function definition *may* be replaced. I want to know precisely when the CallInst is a call to a function that I am going to instrument as part of my pass (ignore indirect invocations for the moment). Obviously I could do an initial pass and build an explicit list of such functions. But is there an easier way by just looking at the Function object? I guess I am looking for something like F->IsGoingToGetReplacedAtLinkTime(). Actually, that seems like it is probably impossible to resolve during the pass.