Hi Jon, The last I heard about tail calls was http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-November/027355.html when you questioned why doing tail calls with no optimization caused llc to barf. It mentions a revision number but that post is only a few days old so I hope it is fixed in the trunk. --Sam Crow ----- Original Message ----> From: Jon Harrop <jon at ffconsultancy.com> > To: llvmdev at cs.uiuc.edu > Sent: Wed, November 25, 2009 1:19:28 PM > Subject: [LLVMdev] Possible bug in TCO? > > > My compiler is generating a bunch of code including the following line: > > %57 = call fastcc i32 @aux(%1* %0, %1 %1, %1 %46, i32 0, %4 %2) ; > [#uses=1] > ret i32 %57 > > The program works fine as long as this isn't a tail call. If I compile via > a .ll and insert "tail" by hand, the program segfaults. However, if I make it > a tail call and return an undef i8* or void instead of the i32 0 then it > works (the source code is returning the value () of the type unit in ML, so > it conveys no information and can be returned as anything). That makes me > think this has been a bug in LLVM rather than in my own code. > > I'm using LLVM 2.6. Anyone recognise this as a bug in TCO fixed since then or > should I try to boil it down and submit it? > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
My compiler is generating a bunch of code including the following line: %57 = call fastcc i32 @aux(%1* %0, %1 %1, %1 %46, i32 0, %4 %2) ; <i32> [#uses=1] ret i32 %57 The program works fine as long as this isn't a tail call. If I compile via a .ll and insert "tail" by hand, the program segfaults. However, if I make it a tail call and return an undef i8* or void instead of the i32 0 then it works (the source code is returning the value () of the type unit in ML, so it conveys no information and can be returned as anything). That makes me think this has been a bug in LLVM rather than in my own code. I'm using LLVM 2.6. Anyone recognise this as a bug in TCO fixed since then or should I try to boil it down and submit it? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e
On Wednesday 25 November 2009 19:19:28 Jon Harrop wrote:> I'm using LLVM 2.6. Anyone recognise this as a bug in TCO fixed since then > or should I try to boil it down and submit it?I've come up with the following minimal repro that segfaults on my machine: define fastcc i32 @g({i32, {i32, i32}}) { %1 = extractvalue {i32, {i32, i32}} %0, 0 %2 = extractvalue {i32, {i32, i32}} %0, 1 %3 = extractvalue {i32, i32} %2, 0 %4 = extractvalue {i32, i32} %2, 1 %5 = add i32 %1, %3 %6 = add i32 %5, %4 ret i32 %6 } define fastcc i32 @f({i32, {i32, i32}}) { %1 = tail call fastcc i32 @g({i32, {i32, i32}} %0) ret i32 %1 } define i32 @main() { %1 = insertvalue {i32, {i32, i32}} undef, i32 1, 0 %2 = insertvalue {i32, i32} undef, i32 2, 0 %3 = insertvalue {i32, i32} %2, i32 3, 1 %4 = insertvalue {i32, {i32, i32}} %1, {i32, i32} %3, 1 %5 = call i32 @f({i32, {i32, i32}} %4) ret i32 %5 } I believe this is a bug in the handling of nested structs across tail calls. There is no pointer manipulation or allocation in this code yet valgrind says it dies trying to access memory location 0x1. I'll try with the latest SVN repo to see if it works... -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e
Jon Harrop wrote:> I've come up with the following minimal repro that segfaults on my machine:Jon, were you able to resolve this? FWIW, TOT is causing all kinds of weird segfaults related to tail calls in my Pure interpreter, too (at least on x86-64). In my case these seem to be limited to the JIT, however (batch-compiled Pure programs via opt+llc all work fine, even with TCO), so it's probably a different issue. When using JIT compilation, the Pure interpreter works fine with LLVM 2.3 thru 2.6, and also with early revisions of 2.7svn, but it fails most of my test suite with current TOT, even though the generated IR seems to be the same as before. Have there been any changes to the x86-64 backend of the JIT which might break tail call elimination? I didn't see any announcements about major changes in the JIT on the ml, so I have no idea what might be going wrong there. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag