similar to: [LLVMdev] Mixing calling conventions

On Dec 17, 2008, at 9:14 PM, Jon Harrop wrote: > > Are you not supposed to be able to call a FastCC function from a CCC > function? > > I'm calling a CCC "main" function from OCaml and that "main" > function calls > internal functions that require tail calls. With CCC everywhere it > works > (except I don't get tail calls). If I use

My compiler is generating a bunch of code including the following line: %57 = call fastcc i32 @aux(%1* %0, %1 %1, %1 %46, i32 0, %4 %2) ; <i32> [#uses=1] ret i32 %57 The program works fine as long as this isn't a tail call. If I compile via a .ll and insert "tail" by hand, the program segfaults. However, if I make it a tail call and return an undef i8* or void instead

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

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: define fastcc { { i8*, i8* }*, i8* } @init({ { i8*, i8* }*, i8* }, i32) { entry: %2 = alloca { i32, { { i8*,

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

Unless I am mistaken, LLVM barfs if I try to pass an LLVM function to another function as an argument because functions are second class. However, if I const bitcast the LLVM function to a function pointer when it is defined then I can use that as a first-class function pointer. In particular, I can invoke it directly by emitting a "call" without having to cast it back beforehand.

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

What is the current status of multiple return values in LLVM and are there any further plans? In particular, if a function returns a struct will it be handled (assuming fastcc) more efficiently than having the caller stack allocate space for it and pass that by reference to the callee to fill in? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com

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

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

On Friday 06 February 2009 03:33:57 Chris Lattner wrote: > On Feb 5, 2009, at 3:42 PM, Jon Harrop wrote: > > Unless I am mistaken, LLVM barfs if I try to pass an LLVM function > > to another > > function as an argument because functions are second class. > > Huh? can you give an example as llvm IR? You can certainly pass > functions by-value as a function pointer.

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

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

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

On Monday 23 February 2009 16:14:57 Arnold Schwaighofer wrote: > The problem has to do with how struct returns are represented > internally by llvm (in the SelectionDAG) and how the tail call > optimization implementation checks if it may perform the tail call. > The implementation checks that the <call> node is immediately followed > by a <ret> node. A struct return

On Tuesday 24 February 2009 00:16:37 Dan Gohman wrote: > On Feb 23, 2009, at 5:59 AM, Anton Korobeynikov wrote: > > This is not true in general and highly target- and CC- dependent. For > > example, you can ran out of registers and then your struct can be > > passed > > partly in registers and partly on stack. And depending on the stack > > frame size of the callee