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 1C065BBC4 for ; Sat, 21 Mar 2009 14:32:41 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8BAC+JxEnUnwdjjWdsb2JhbACCH5NSAQEJCQoJDwa+PIN+Bg X-IronPort-AV: E=Sophos;i="4.38,399,1233529200"; d="scan'208";a="36935568" Received: from relay.pcl-ipout01.plus.net ([212.159.7.99]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 21 Mar 2009 14:32:40 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFALeIxEnUnw4S/2dsb2JhbACCH9JLg34G Received: from pih-relay05.plus.net ([212.159.14.18]) by relay.pcl-ipout01.plus.net with ESMTP; 21 Mar 2009 13:32:39 +0000 Received: from [87.115.86.1] (helo=leper.local) by pih-relay05.plus.net with esmtp (Exim) id 1Ll1JW-0001Bu-6l for caml-list@yquem.inria.fr; Sat, 21 Mar 2009 13:32:39 +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 13:38:32 +0000 User-Agent: KMail/1.9.9 References: <200903211439.47107.cdome@bk.ru> In-Reply-To: <200903211439.47107.cdome@bk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903211338.32805.jon@ffconsultancy.com> X-Plusnet-Relay: 38093d378a07faf154b4717c95b9e7e8 X-Spam: no; 0.00; ocaml:01 ocaml:01 mismatch:01 compilation:01 extensively:01 compilation:01 ocamlopt:01 hppa:01 mips:01 powerpc:01 ocamlopt:01 run-time:01 compiler:01 lacks:01 run-time:01 On Saturday 21 March 2009 12:39:45 Andrey Riabushenko wrote: > Hi OCaml hackers, > > It is not mistake, in spite of ocaml does not take part in GSoC 2009, but > ocaml community still can benefit from it. > > I would like to develop LLVM frontend to Ocaml language. LLVM does > participate in GSoC. LLVM do not mind to developed a ocaml frontend as LLVM > GSoC project. I want to discuss details with you before I will make an > official proposal to LLVM. I recommend you peruse the LLVM and HLVM mailing lists for information about current work along similar lines: http://hlvm.forge.ocamlcore.org > 1. What is the best way to make ocaml frontend on your opinion? The impedance mismatch between the current OCaml compilers and LLVM is high: . The OCaml compilers remove type information in the early stages of compilation but LLVM is a typed assembler and needs that information to be conveyed all the way through to the back end. . The OCaml compilers make no attempt to provide reusable intermediate representations. So you will probably end up hacking extensively on ocamlopt's internals and, consequently, your code will be bound by the QPL license even though you will probably not salvage much. This is why I started from scratch. > I think the best would to way to develop ocaml llvm front end as a part of > ocaml distribution. I don't not want to develop yet another a separate > project, which is half-done llvm frontend that nobody uses. There are > plenty of those for other languages lying around. I propose to forget about > JIT capabilities of LLVM and concentrate on AOT compilation for now. JIT is the single most important benefit of LLVM in the context of OCaml. With JIT: . You can instantiate polymorphic definitions for each combination of type parameters that they are used with, providing substantial performance improvements. . You can generate code that is optimized for the current machine. . You can provide a performant top-level. Forgetting about JIT would certainly be a mistake. > Ocamlopt currently generates native assembler for the following platforms: > i386, AMD64, ia64, arm, hppa, alpha, m68k, mips, powerpc, sparc assembler. > I propose to add LLVM assembler generation as another platform to ocamlopt. > It requires the least modification of ocaml source and easy to maintain. There are many problems with this: . You will succumb to ocamlopt's current run-time representation which is objectively inefficient (e.g. boxing floats, tuples, records) and was only chosen because the compiler lacks capabilities that LLVM already provides for you (primarily JIT compilation). . LLVM's optimization passes will not optimize the representations and, consequently, performance will not be improved. . You will inherit ocamlopt's most serious flaws: its run-time and its FFI. . If you inherit ocamlopt's run-time then you will need to be able to generate compliant code from LLVM which is extremely difficult, error prone and almost entirely untested. > LLVM will give ocaml an aggressive whole program optimizer... I doubt you could even match the performance of OCaml's existing compiler with that approach, much less beat it. There are two reasons for this: . Building upon ocamlopt's internal run-time representation (e.g. boxed tuples) ties LLVM's hands behind its back when it comes to optimization. LLVM could do very little to optimize such code. . LLVM's existing optimization passes work great on naively-generated C or C++ code but they know nothing about parametric polymorphism, closures and pattern matching. These high-level language features are where the most beneficial optimizations lie. For example, applying LLVM's optimization passes to HLVM generated code only give ~15% performance improvements. > Question to the Ocaml creators and maintainers. > > 2. Will you merge LLVM platform to the ocaml trunk assuming that it works > as it should? Collaboration with the existing HLVM effort would probably be far more productive. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e