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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 0BCB0BC57 for ; Fri, 3 Dec 2010 15:32:43 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKeO+Ew+3JIE/2dsb2JhbACUb45GccJxghSDNASKa4MS X-IronPort-AV: E=Sophos;i="4.59,293,1288566000"; d="scan'208";a="81243397" Received: from vs.philou.ch ([62.220.146.4]) by mail4-smtp-sop.national.inria.fr with ESMTP; 03 Dec 2010 15:32:42 +0100 Received: from [192.168.1.120] (85-218-12-23.dclient.lsne.ch [85.218.12.23]) by vs.philou.ch (Postfix) with ESMTPSA id 9D7731F29BB7 for ; Fri, 3 Dec 2010 15:39:51 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT) From: Philippe Strauss In-Reply-To: Date: Fri, 3 Dec 2010 15:32:40 +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.1082) X-Spam: no; 0.00; ocamlopt:01 arrays:01 ocamlopt:01 runtime:01 runtime:01 ocaml:01 ocaml:01 beginner's:01 bug:01 beginners:01 stack:01 compilers:01 exception:01 exception:01 emit:01 I'm totally noob on compilers internals, but if the processing of float = arrays can be improved a lot by a LLVM ocamlopt, I would use it = exclusively. Le 3 d=E9c. 2010 =E0 11:03, Benedikt Meurer a =E9crit : > 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: >=20 > 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). >=20 > 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. >=20 > 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). >=20 > 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). >=20 > 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. >=20 > 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? >=20 > 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. >=20 > 2. Some interesting optimizations and all the standard optimizations = for free. >=20 > 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. >=20 > 4. And for the kids: LLVM is cool, OCaml will use LLVM, so OCaml is = also cool. ;-) >=20 > Anything I forgot to mention? Comments? >=20 > 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