From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id EDEA4BBC4 for ; Sat, 21 Mar 2009 22:29:34 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUAAIL4xEnUnwdkimdsb2JhbACCHpNPAQEBCgkMBw8GvWWDfgY X-IronPort-AV: E=Sophos;i="4.38,401,1233529200"; d="scan'208";a="36950554" Received: from relay.pcl-ipout02.plus.net ([212.159.7.100]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 21 Mar 2009 22:29:34 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgEADf5xEnUnw4R/2dsb2JhbACCHtF4g34G Received: from pih-relay04.plus.net ([212.159.14.17]) by relay.pcl-ipout02.plus.net with ESMTP; 21 Mar 2009 21:29:33 +0000 Received: from [87.115.86.1] (helo=leper.local) by pih-relay04.plus.net with esmtp (Exim) id 1Ll8l3-0005Yx-Bi for caml-list@yquem.inria.fr; Sat, 21 Mar 2009 21:29:33 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Google summer of Code proposal Date: Sat, 21 Mar 2009 21:35:28 +0000 User-Agent: KMail/1.9.9 References: <200903211439.47107.cdome@bk.ru> <200903211451.50723.jon@ffconsultancy.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903212135.28525.jon@ffconsultancy.com> X-Plusnet-Relay: 185e94498086eb2f61af98a20fb70840 X-Spam: no; 0.00; struct:01 struct:01 pointer:01 ocaml:01 non-standard:01 high-level:01 pointers:01 subtleties:01 ocaml:01 2009:98 frog:98 wrote:01 wrote:01 caml-list:01 functions:01 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