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 8667ABC57 for ; Fri, 3 Dec 2010 11:03:58 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AANZP+ExKfVK0kGdsb2JhbACjLQgWAQIJCQwHEQQeqBaMAAEFjgoBBIIUgzQ X-IronPort-AV: E=Sophos;i="4.59,292,1288566000"; d="scan'208";a="82239891" Received: from mail-wy0-f180.google.com ([74.125.82.180]) by mail2-smtp-roc.national.inria.fr with ESMTP; 03 Dec 2010 11:03:58 +0100 Received: by wyb29 with SMTP id 29so4482358wyb.39 for ; Fri, 03 Dec 2010 02:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=oKMlDo3Nyfyu4gTM3M9OSkBZUPPuUXcFZJHYPuvz5Dw=; b=I6Qx0cQvgqRW2NrPcBt1U1XoASKWDy1p12Cm17z+4h+RM6oX/KbY45HS8oo50/ko5Z /Qr1q36TnXY6D66oAGFaDXFVGuMrWjyLqPigO0Xoou0+QzEwAT9B2pPoxL83pLWfHMmp /gudhbPo9Mhlgw8Hn8FL0N/DW5imNr/BPBF0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=uNeSuPpWbqsu1sgUwNmSh9lW+MH2pzvTJAdyi0InZefQe1zvM903lDsTaeZPrPK3ba jmRHpdo5Bxry6t5TTWFk7t6cHnERL5RFnaZ1nNVMAxVR5UmI7aMhvSOKntWnrSAW2KSb ZKBDw+weJu2r1pG+RiG4XbS0vTcz5o28eh6rI= Received: by 10.227.152.21 with SMTP id e21mr1543068wbw.188.1291370637938; Fri, 03 Dec 2010 02:03:57 -0800 (PST) Received: from bespin.informatik.uni-siegen.de (bespin.informatik.uni-siegen.de [141.99.131.92]) by mx.google.com with ESMTPS id 11sm1114799wbj.1.2010.12.03.02.03.56 (version=SSLv3 cipher=RC4-MD5); Fri, 03 Dec 2010 02:03:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT) From: Benedikt Meurer In-Reply-To: <0b9301cb91a3$8f42fd60$adc8f820$@com> Date: Fri, 3 Dec 2010 11:03:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; ocamlopt:01 ocamlopt:01 runtime:01 runtime:01 ocaml:01 ocaml:01 stack:01 exception:01 exception:01 emit:01 emit:01 caml-list:01 ghc:01 conventions:02 data:02 So, let's take that LLVM thing to a somewhat more serious level (which = means no more arguing with toy projects that simply ignore the difficult = stuff). 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 .ll 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 = OCaml 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 intrinsics to support allocation and exception handling = with appropriate lowering for the targets (somewhat difficult and = questionable whether this will be merged into LLVM, since it's usable by = OCaml only). 3b. Alternatively we could also replace the native interface of the = current 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). Allocation and GC are possible without too many changes here, = but the exception 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 modes provided by LLVM (overhead, most probably). 4. We need a way to emit Cmm data items. LLVM cannot handle this ATM, = which should be fixed (dunno how yet). In the meantime we can emit Cmm = data items using module level asm. It is important to note that we won't get anything for free. Work is = required for every single platform we plan to support using the LLVM = backend. This 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, there'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 burden 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 = languages using LLVM will not be faced with the same problems again. = Dunno if that'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=