similar to: [LLVMdev] Possible bug in TCO?

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,

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

Hi all, I've added tail call optimization to x86. This is different from what -tailcallopt does, which forces fastcc function to be tail callable. My changes detect opportunities to do tail call without having to change the ABI. I've looked at the codegen of -tailcallopt and it doesn't look all that good. Running it as a llcbeta option shows it significantly pessimize code in most

I'm toying with benchmarks on my HLVM and am unable to get any performance improvement from optimization passes. Moreover, some of my programs generate a lot of redundant code (e.g. alloca a struct, store a struct into it and read only one field without using the rest of the struct) and this does not appear to be optimized away. I simply copied the use of PassManager from the Kaleidoscope

Which of LLVM's backends support TCO? It seems to work on x86 and x64 but what about ARM etc.? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

On Friday 13 November 2009 04:57:43 David Terei wrote: > I've run into some issues with tail calls in the past, make sure you > are doing the following: > > 1. Call should be marked with tail (obviously) > 2. Next statement after tail call should be 'return void' > 3. Use fast call convention for tail calls > 4. Make sure the function you are calling doesn't

On Nov 13, 2009, at 3:34 AM, Jon Harrop wrote: >> Point 4 is the one that caused me trouble for some time. >> Unfortunately >> it causes a bad interaction with the optimiser, specifically the >> 'simplifycfg' pass. What seems to happen is that since the function >> you are calling is marked with 'noreturn', the simplifycfg pass will >> then

On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Monday 04 January 2010 03:33:06 Simon Harris wrote: >> On 04/01/2010, at 3:01 PM, Jon Harrop wrote: >> > I am certainly interested in tail calls because my HLVM project relies >> > upon LLVM's tail call elimination. However, I do not understand what tail >> > calls LLVM

As I understand it, first-class structs will allow structs to be passed as function arguments and returned as results (i.e. multiple return values) instead of passing pointers to structs. However, the GEP instruction only handles pointer types. So I do not understand how you will be able to extract the fields of a struct when it is received as a value type. Will the GEP instruction be altered

On Thursday 19 February 2009 19:00:14 Jon Harrop wrote: > I'm toying with benchmarks on my HLVM and am unable to get any performance > improvement from optimization passes... I just disassembled some of the IR before and after optimization. This example function squares a complex number: let zsqr(r, i) = (r*r - i*i, 2*r*i) My compiler is generating: define fastcc i32 @zsqr({

On Monday 04 January 2010 05:16:40 Jeffrey Yasskin wrote: > On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > LLVM's TCO already handles mutual recursion. > > Only for fastcc functions Yes. > compiled with -tailcallopt, right? If you use the compiler, yes. > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > I believe

On Sunday 29 November 2009 02:06:04 you wrote: > > So it will stack overflow on tail calls > > At the moment, yes. But then again, so does java. Sure but a lot of people like me are using LLVM precisely because it offers these wonderful features. As long as your JVM backend does not handle these features correctly its utility is greatly diminished. > Also, it looks like

On Sun, Nov 29, 2009 at 2:19 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > 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

> So it will stack overflow on tail calls At the moment, yes. But then again, so does java. Also, it looks like they're working on support for tail calls in the Da Vinci Machine[1]. > and break with run-time errors When I said it raises an assertion, I meant at compile-time. > on structs? No, structs are supported. The only unsupported types at the moment (as far as I am aware) are

On 04/01/2010, at 3:01 PM, Jon Harrop wrote: > On Monday 04 January 2010 01:12:55 Simon Harris wrote: >> I'm investigating "improving" the TCO facilities in LLVM to provide for >> "hard" tail calls. Specifically, this would involve extending the existing >> implementation to discard the stack frame for the caller before executing >> the callee. I

On Friday 13 November 2009 16:26:01 Chris Lattner wrote: > On Nov 13, 2009, at 3:34 AM, Jon Harrop wrote: > >> Point 4 is the one that caused me trouble for some time. > >> Unfortunately > >> it causes a bad interaction with the optimiser, specifically the > >> 'simplifycfg' pass. What seems to happen is that since the function > >> you are

> > On Thursday 19 February 2009 19:00:14 Jon Harrop wrote: >> I'm toying with benchmarks on my HLVM and am unable to get any >> performance >> improvement from optimization passes... > > I just disassembled some of the IR before and after optimization. > This example > function squares a complex number: Something is definitely wrong with the way

I just upgraded HLVM from LLVM 2.7 to 2.8 and started seeing stack overflows so I think TCO isn't working. Have there been any obvious changes that would cause this? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com

On Monday 04 January 2010 03:33:06 Simon Harris wrote: > On 04/01/2010, at 3:01 PM, Jon Harrop wrote: > > I am certainly interested in tail calls because my HLVM project relies > > upon LLVM's tail call elimination. However, I do not understand what tail > > calls LLVM is not currently eliminating that you plan to eliminate? > > Mutual recursion for a start: >

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