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
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
Nick Lewycky wrote:> Can you prepare a standalone testcase that demonstrates the problem? See > unittests/ExecutionEngine/JIT/*.cpp to get your started.Probably. I'd essentially have to replicate some minimal runtime environment and IR as created by the Pure interpreter. That's doable, but very tedious and will probably take a while. The problems are easy to reproduce by grabbing the Pure svn source from http://pure-lang.googlecode.com/ and running './configure && make && make check', though. Is that good enough? 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