[LLVMdev] Possible bug in TCO?

[Albert Graef]

Jeffrey Yasskin wrote:
> Try batch compiling with the large code model. (llc -code-model=large)
> If that also causes tail calls to break, then I did something wrong in
> fixing far calls in the JIT.

Jeffrey, I took a closer look at this now, and all the TCO-related
weirdness I see in the Pure interpreter is indeed related to your commit
in r88984 ("Make X86-64 in the Large model always emit 64-bit calls").
Up to and including r88983, Pure passes all checks (at least with eager
compilation, see below), with r88984 and later more than half of the
checks fail. This only happens when using dynamic compilation. As I
reported earlier, batch compilation works fine, even if the large code
model is used. OTOH, dynamic compilation is broken no matter which code
model I choose when creating the JIT.

So it seems that r88984 does break fastcc and/or tail calls in the JIT.
Maybe you don't see this in UnladenSwallow because it doesn't do tail calls?

There's also some minor breakage which isn't TCO-related (four failed
checks in the Pure interpreter) when reenabling lazy compilation with
DisableLazyCompilation(false). These seem to go all the way back to your
commit of Nick's patch (r84032 = "Keep track of stubs that are created"
fails exactly the same checks, while r84031 is fine). Those four Pure
checks all involve anonymous closures (lambdas); I still need to look at
Nick's patch to figure out what exactly is going on there.

Now I might be able to live without lazy compilation (even though it
noticably slows down some code), but it goes without saying that as a
functional language Pure definitely needs TCO. So I can only hope that
this will be fixed before the LLVM 2.7 release.

Ok, so what next? Should I submit a bug report? Reopen PR5162?

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