From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id D2644BC57 for ; Fri, 3 Dec 2010 14:34:58 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAAAA6B+EzRVaE0kGdsb2JhbACDUZEdjj4IFgECCQkMBxEEHqhaiSyCVIURiQQBAQMFgRxzgkFzBIRehg2JMg X-IronPort-AV: E=Sophos;i="4.59,293,1288566000"; d="scan'208";a="82281052" Received: from mail-fx0-f52.google.com ([209.85.161.52]) by mail2-smtp-roc.national.inria.fr with ESMTP; 03 Dec 2010 14:34:58 +0100 Received: by fxm5 with SMTP id 5so7624479fxm.39 for ; Fri, 03 Dec 2010 05:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=kvKtbM4/J6EQgO9w6w7htLHtsYHFjvKhSS116MTYtW0=; b=Uo4cPzejWVPz+Z1b+rznZOY2JjrYE3arnZksTxKbgy7Mip2Z3nzj8oUdkCpv6LkdUV DpL5v8AHuzAMWIZTym77BxflKYOaOTULsBNGjoBptcUFL9mY8GW+W9vwVgyDmgDHW3m9 HcTK+pu7qeGCuVgj+ndcr/aomPt/Kh+g7+yYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cbZz6GpPrcBeZdKXBIWYlh8iphTiMGhMie9/zHKAbIJhmC8RaNZ7rbMdQJ33NRrV+U ojCT+txkLBrGnuJzyGWi7p8jkRnCEw24SIgvpLIxF5kuFcKhApGXQml84aQ6O8LK/L9V x5oLPRZI7RbzkytvtvWVS48LEmbjwQjGs5VwQ= MIME-Version: 1.0 Received: by 10.223.125.207 with SMTP id z15mr2089571far.42.1291383296652; Fri, 03 Dec 2010 05:34:56 -0800 (PST) Sender: till.varoquaux@gmail.com Received: by 10.223.74.5 with HTTP; Fri, 3 Dec 2010 05:34:56 -0800 (PST) In-Reply-To: References: <3DCEA910-1382-47E5-876B-059178F8F82E@googlemail.com> <20101130124803.7952fca1@deb0> <0a8b01cb90da$da5e6240$8f1b26c0$@com> <5E2DA3F1-7998-4F62-B617-7B6451D1001D@googlemail.com> <0b3b01cb9161$a81c8e10$f855aa30$@com> <0b9301cb91a3$8f42fd60$adc8f820$@com> Date: Fri, 3 Dec 2010 08:34:56 -0500 X-Google-Sender-Auth: CGyyEqvkb-teHXS19YzXQ1-LeOc Message-ID: Subject: Re: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT) From: Till Varoquaux To: Benedikt Meurer Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocamlopt:01 ocaml:01 compiler:01 combinator:01 functors:01 inlining:01 compiler:01 cheers:01 ocamlopt:01 runtime:01 runtime:01 ocaml:01 beginner's:01 bug:01 beginners:01 Thanks for the summary. You seem to think LLVM wouldn't actually buy us much in term of optimisations. In my experience the current ocaml compiler is really good when writing code fairly low level but discourages use of combinator library, higher order functions, functors in performance sensitive code (i.e. you have to do inlining, specialization, constant propaagation etc... by hand). I was under the impression that some of LLVM passes could be a good match for those problems. That is: micro benchmark code that is written carefully with those constraints in mind wouldn't gain much but some form of "origami" programming could be unfolded by the compiler. Am I missing something obvious? (e.g. need for better side effect analysis). Cheers, Till On Fri, Dec 3, 2010 at 5:03 AM, Benedikt Meurer wrote: > So, let's take that LLVM thing to a somewhat more serious level (which me= ans no more arguing with toy projects that simply ignore the difficult stuf= f). What would be necessary to support LLVM in ocamlopt, and what would be = the benefits? First, what has to be done: > > 1. Obviously, one would need to emit LLVM code from ocamlopt (starting at= the Cmm level). Following the GHC/EHC approach we could simply emit the .l= l file here as a starting point (no fiddling with the LLVM API then, could = still switch to the LLVM API later for runtime code generation). > > 2. LLVM would need to generate the stack maps for the GC and the required= symbols for the program (code_begin, code_end, data_begin, data_end). LLVM= already contains an OcamlGCPrinter class, which seems to do exactly this; = so this may be easy. > > 3a. If the current runtime is to be reused, LLVM will have to support OCa= ml calling conventions (easy to implement, did that already), LLVM must be = taught about the OCaml runtime state (i.e. %r14 and %r15 on x86-64 must not= be used by LLVM, also easy to implement), and LLVM must be extended with i= ntrinsics to support allocation and exception handling with appropriate low= ering for the targets (somewhat difficult and questionable whether this wil= l be merged into LLVM, since it's usable by OCaml only). > > 3b. Alternatively we could also replace the native interface of the curre= nt runtime with something that fits better with what is already provided by= LLVM (which isn't a lot, so we would have to limit ourselves somewhat). Al= location and GC are possible without too many changes here, but the excepti= on handling is really difficult, since LLVM doesn't provide anything usable= here; we'd either need to do everything by hand or use one of the two mode= s provided by LLVM (overhead, most probably). > > 4. We need a way to emit Cmm data items. LLVM cannot handle this ATM, whi= ch should be fixed (dunno how yet). In the meantime we can emit Cmm data it= ems using module level asm. > > It is important to note that we won't get anything for free. Work is requ= ired for every single platform we plan to support using the LLVM backend. T= his is probably the case for every serious programming language (and no, we= don't need another mention of HLVM here, it's a toy, that's all). So, ther= e's some boring and probably some interesting work to be done, but what do = we gain? > > 1. Reduce lines of code and improved maintainability of ocamlopt once all= targets are replaced with the LLVM backend. But as said, this does itself = come at a cost, and depending on whether 3a. or 3b. is implemented, we burd= en ourselves with maintaining code within LLVM. > > 2. Some interesting optimizations and all the standard optimizations for = free. > > 3. A better LLVM. If we do it right, other's implementing functional lang= uages using LLVM will not be faced with the same problems again. Dunno if t= hat's possible. > > 4. And for the kids: LLVM is cool, OCaml will use LLVM, so OCaml is also = cool. ;-) > > Anything I forgot to mention? Comments? > > Benedikt > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >