Browse thread
Google summer of Code proposal
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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