similar to: [LLVMdev] Broke my tail (call)

Hi Jon, > I have written a variety tests of tail calls for my HLVM and all passed with > flying colors until I wrote this test (which is actually for algebraic > datatypes) and discovered that it segfaults after ~100k iterations through > what I think should be a tail call. Here's the IR: is this really a tail call? I didn't look closely but at a glance it seems to be

On Sunday 22 February 2009 20:36:52 Duncan Sands wrote: > Hi Jon, > > > I have written a variety tests of tail calls for my HLVM and all passed > > with flying colors until I wrote this test (which is actually for > > algebraic datatypes) and discovered that it segfaults after ~100k > > iterations through what I think should be a tail call. Here's the IR: >

Hello Duncan and Jon, I am the criminal responsible for the tail call implementation in the backends. On Mon, Feb 23, 2009 at 9:17 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jon, > >> >From what I have understood of the LLVM docs about when tail calls get >> eliminated on x86 and x64 it should be a tail call, yes. See below. > this list is for the code

On Tue, Feb 24, 2009 at 11:50 AM, Jon Harrop <jon at ffconsultancy.com> wrote: > Thanks for the clarification. That makes a lot more sense! > > LLVM's support for structs is wonderful but I don't think they can be > called "first-class structs" until all such arbitrary restrictions have been > removed, even though the workaround (using sret form) is trivial

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

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 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: >

On Monday 23 February 2009 12:08:00 Arnold Schwaighofer wrote: > Hello Duncan and Jon, > > I am the criminal responsible for the tail call implementation in the > backends. Thanks! :-) > On Mon, Feb 23, 2009 at 9:17 AM, Duncan Sands <baldrick at free.fr> wrote: > > Hi Jon, > > > >> >From what I have understood of the LLVM docs about when tail calls

The LLVM 2.6-compatible IR below is derived from the HLVM test suite and is one of the things I've noticed going wrong. However, I just discovered that it works with LLVM 2.6 and with LLVM SVN when run through lli or llc without -tailcallopt but when I use: $ llvm-as -f aout.ll $ llc -tailcallopt -f aout.bc -o aout.s $ gcc -lm aout.s -o aout and the latest LLVM SVN it starts to print

On Tuesday 24 February 2009 14:54:12 Arnold Schwaighofer wrote: > On Tue, Feb 24, 2009 at 11:50 AM, Jon Harrop <jon at ffconsultancy.com> wrote: > > Thanks for the clarification. That makes a lot more sense! > > > > LLVM's support for structs is wonderful but I don't think they can be > > called "first-class structs" until all such arbitrary

On Mon, Feb 23, 2009 at 2:13 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > Moreover, I now have evidence that LLVM is not behaving as you expect: > > 3. Adjusting the return value from this function into sret form results in > tail call elimination being performed correctly. Note that this is still > passing a first-class struct by value as an argument to a function

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

tail calls are only implemented for fastcall calling convention if i remeber right from my inquiries. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091112/e8f1dd2a/attachment.html>

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

Two related questions. This is with LLVM 2.4 doing a JIT compile to x86-64. (I generate LLVM IR using an IRBuilder instance, compile/optimize, and then call getPointerToFunction() to get a "native" function pointer.) (1) My reading of various mailing list messages seems to indicate that a function marked as using the "fastcc" calling convention

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

Hi Jon, > >From what I have understood of the LLVM docs about when tail calls get > eliminated on x86 and x64 it should be a tail call, yes. > > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > . Caller and callee have the calling convention fastcc. > . The call is a tail call - in tail position (ret immediately follows call and > ret uses value of call or

I was playing with optimization switches to llc to see how fast I could get it to compile but it keeps barfing. Tinkering indicates that llc barfs particularly when -tailcallopt is given in combination with other flags. For example, without -tailcallopt works in a couple of ways: $ llc -O0 -f aout.bc -o aout.s $ llc -O0 --regalloc=local -f aout.bc -o aout.s But fails with -tailcallopt with

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