[LLVMdev] Possible bug in TCO?

Nick Lewycky nicholas at mxc.ca
Tue Dec 8 00:03:10 PST 2009


Albert Graef wrote:
> 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?

Can you prepare a standalone testcase that demonstrates the problem? See 
unittests/ExecutionEngine/JIT/*.cpp to get your started.

Nick



More information about the llvm-dev mailing list