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.9 required=5.0 tests=AWL,FUZZY_VLIUM autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 07A1CBBC4 for ; Sat, 21 Mar 2009 15:45:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwCAIaaxEnUnwdkimdsb2JhbACCHpNSAQoJEw8GviSCXQOBHgY X-IronPort-AV: E=Sophos;i="4.38,399,1233529200"; d="scan'208";a="26030080" Received: from relay.pcl-ipout02.plus.net ([212.159.7.100]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 21 Mar 2009 15:45:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAEqaxEnUnw6U/2dsb2JhbACCHtIwgl0DgR4G Received: from fhw-relay07.plus.net ([212.159.14.148]) by relay.pcl-ipout02.plus.net with ESMTP; 21 Mar 2009 14:45:56 +0000 Received: from [87.115.86.1] (helo=leper.local) by fhw-relay07.plus.net with esmtp (Exim) id 1Ll2SR-0005ej-4f for caml-list@yquem.inria.fr; Sat, 21 Mar 2009 14:45:55 +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 14:51:50 +0000 User-Agent: KMail/1.9.9 References: <200903211439.47107.cdome@bk.ru> <5b0248170903210601pf3845d8h21bdd6a5ab1147af@mail.gmail.com> <200903211547.41996.cdome@bk.ru> In-Reply-To: <200903211547.41996.cdome@bk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903211451.50723.jon@ffconsultancy.com> X-Plusnet-Relay: b084abad355f8fbdbc4e18a589416a51 X-Spam: no; 0.00; ocaml:01 ocaml:01 parametric:01 polymorphism:01 parametric:01 polymorphism:01 structs:01 struct:01 struct:01 pointer:01 lennart:01 augustsson:01 vectors:01 vastly:01 bindings:01 On Saturday 21 March 2009 13:47:40 Andrey Riabushenko wrote: > > > LLVM > > > will give ocaml an aggressive whole program optimizer and will make > > > possible to run ocaml on new platforms that are supported by LLVM, but > > > not yet by Ocaml. > > > > Is there any such platform? > > There are - PIC16, XCore, Cell SPU and Microsoft IL (F# reinvented :). > Many others are under development. Both OCaml and LLVM support x86, x64 and ARM as well as having backends for many other architectures that are of questionable quality. For example, LLVM's CIL backend was broken when I tried it and, of course, it cannot even support generics because LLVM is incapable of expressing parametric polymorphism. For OCaml, there is OCamIL for generating CIL but it also does not support parametric polymorphism because it is for .NET 1.1. I have been developing with LLVM for many months now and I have had two main gripes: 1. LLVM calls abort() instead of raising an exception and that makes it almost impossible to debug LLVM code because it just dies immediately upon hitting any error and gives only the most convoluted contextless error messages. The best solution I have found is to litter your LLVM IR emitter with debug printfs. HLVM overcomes this problem by catching and handling type errors appropriately, making it much easier to use. 2. Many of LLVM's features sound alluring but turn out to be unusable. Fortunately, the two core features required to support languages like OCaml robustly and efficiently (tail calls and first-class structs) are almost completely working. Most of HLVM's development effort has gone into rejecting or working around features that do not work correctly in LLVM. Just to give some examples: . 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. . Lennart Augustsson found that LLVM's vector intrinsics can generate broken SSE code for 2D vectors. There is no general workaround: you are expected to special-case this situation in all front-ends (!). . Many people have written to me because they have been unable to get LLVM's GC API to work at all. Upon hearing the issues, I immediately opted to use a shadow stack designed for an uncooperative environment in HLVM. This at least works but it is needlessly inefficient. . OCaml is vastly superior to C++ for writing compilers but the OCaml bindings to LLVM are far from complete. HLVM includes its own auxiliary bindings for many important features such as first-class structs and enabling tail calls. LLVM is a great tool and a wonderful opportunity but it is not a panacea and it would be wise to learn such lessons before jumping in to LLVM-based development. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e