Version française
Home     About     Download     Resources     Contact us    
Browse thread
Google summer of Code proposal
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Google summer of Code proposal
On Saturday 21 March 2009 20:49:28 Joel Reymont wrote:
> On Mar 21, 2009, at 2:51 PM, Jon Harrop wrote:
> > . I found that LLVM's x86 backend breaks tail calls when the return
> > type is a
> > first class struct. The workaround is to use sret form, having the
> > caller
> > preallocate the return struct and passing a pointer to the struct as
> > an extra
> > first argument.
>
> Returning a structure by having the caller preallocate space, etc. is
> part of the Intel ABI or something like that. This is how it's done,
> period.

No, not at all. Other calling conventions have many benefits including better 
performance and the ability to return multiple values. LLVM provides a "fast" 
calling convention as well as the (Intel-compatible) C callcc for precisely 
this reason. HLVM uses LLVM's fast callcc. OCaml uses its own non-standard 
calling convention.

Indeed, if HLVM were not using fastcc it would not have any tail calls at all!

This raises some interesting issues. For example, HLVM allows you to declare 
external C functions from your high-level language and call them directly. 
But it also has first-class function pointers so it is necessary to wrap the 
C calls in fastcc calls so the C functions can be used interchangeably with 
internal functions. There are many such subtleties in the design of HLVM and 
I described them all in the relevant OCaml Journal articles.

> Not sure how it relates to breaking tail calls, though.

A design flaw in the implementation of tail calls in LLVM requires code to be 
injected by the architecture-specific code gen after the tail call and before 
the actual return in order to move the struct elements into place. That 
prevents such tail calls from being eliminated later in the code gen.

Fortunately the author was there to assist. Even more remarkably, the same 
student is responsible for tail calls on the JVM (!). He must be busy...

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e