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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 70E24BC57 for ; Tue, 30 Nov 2010 18:57:09 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4BAH/J9EzRVaE0kGdsb2JhbACjCwgVAQEBAQkJDAcRAx+pfolkghiFQi6IVgEBAwWCDoM0BI5Zggo X-IronPort-AV: E=Sophos;i="4.59,281,1288566000"; d="scan'208";a="90430495" Received: from mail-fx0-f52.google.com ([209.85.161.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Nov 2010 18:57:09 +0100 Received: by fxm5 with SMTP id 5so4678192fxm.39 for ; Tue, 30 Nov 2010 09:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=HElezjtpXcP7wt/XLEJmHe1Wb/kfPAsV/3ktnwtpP3M=; b=Wre6LgBkRM1D/UfBXf9lEkdFL/JIqj/QK846I3QfbrzC2SkCg0TmH9RhQe6WmRqnzz K2/+6S9GIrnvK5URPyDBHBBiN65CKL/LK5SG8ByaWB6iCYozXoF3Y0x8fXIsKvVzDaHI d1cbx7BaL/bFiK0jvLS0lAsOJdIoG5SZBWHQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=k4x/+P81Dq7LH23aBcy4gkDSYrEdgWWl7NRU9QKhWUe2lSLuJ69XxQw0XMI/NCy7me yRBnL7q54J+TYayg5vuCuX3ah8ITi+XAgOZG90/pOseEOO4a9ai5RJHyiaJu0ZfbLOMc Ppsyi+N468PYrBFSx6vk1ZzQA/fUFzrhCQdlk= Received: by 10.223.83.200 with SMTP id g8mr7155143fal.98.1291139826805; Tue, 30 Nov 2010 09:57:06 -0800 (PST) Received: from deb0 ([79.114.97.111]) by mx.google.com with ESMTPS id n15sm1736580fam.36.2010.11.30.09.57.05 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Nov 2010 09:57:06 -0800 (PST) Date: Tue, 30 Nov 2010 19:26:00 +0200 From: =?UTF-8?B?VMO2csO2aw==?= Edwin To: bluestorm Cc: Benedikt Meurer , caml-list@yquem.inria.fr Subject: Re: [Caml-list] OCamlJIT2 vs. OCamlJIT Message-ID: <20101130192600.35698cde@deb0> In-Reply-To: References: <3DCEA910-1382-47E5-876B-059178F8F82E@googlemail.com> <20101130124803.7952fca1@deb0> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocamlopt:01 ulambda:01 byte-code:01 ocamlopt:01 ocaml:01 bytecode:01 ulambda:01 low-level:01 ocaml:01 ocaml's:01 ocaml's:01 bytecode:01 compiler:01 compiler:01 non-trivial:01 On Tue, 30 Nov 2010 18:01:28 +0100 bluestorm wrote: > On Tue, Nov 30, 2010 at 11:55 AM, Benedikt Meurer < > benedikt.meurer@googlemail.com> wrote: > > > > LLVM backend for ocamlopt is a totally different story. You'd have > > to start with the Ulambda or the Cmm intermediate representation, > > while a JIT approach starts with the byte-code representation (not > > necessarily, but that was the case for our approach). > > > > However, I'm not sure there would be any immediate benefit from > > using LLVM as code generator backend for ocamlopt, since ocamlopt > > already does a quite good (and fast) job. I thought you already had some code to do that, but thrown it away because the JIT was too slow. Was just trying to point out that such code shouldn't be thrown away completely. Did the LLVM code you had take OCaml bytecode or Ulambda/Cmm as input? > > So besides probably > > educational or research interests, what would be the practical > > benefit of LLVM inside ocamlopt? > > > > There would be several advantages in switching to LLVM for code > generation. The general idea is that if other people work on the > low-level stuff, it is less work for the OCaml implementors. > > - more portability : while I'm not sure LLVM is ported to more > platforms than OCaml right now, OCaml's tier 1 platforms are supported by LLVM. Ocaml's tier 2 support has more architectures than LLVM though. > the LLVM community will probably port > its bytecode to numerous architectures in the future; I've seen some microcontroller backends added lately, but I've also seen unmaintained and broken backends removed (IA-64 for example). > in contrast, > maintining numerous backend in the OCaml compiler has a maintainance > cost. In particular, cross-compilation would probably be easier. > > - more optimizations : the LLVM guys try to develop a wide range of > optimization passes between LLVM IR and native code, while ocamlopt is > mostly a "non-optimising compiler". It's not clear however how much > gain we could have, as OCaml has already optimized the most important > parts, and a big part of the performance concerns are outside the > LLVM area (data representation and GC). Still, the experience of > GHC-LLVM has been quite positive, with noticeable improvements in > some cases. > > On the other hand, it may be non-trivial to adapt LLVM to cope with > the OCaml runtime, the GC in particuliar, and that would probably > involve upstream changes to LLVM. There is some support for emitting (assembly, not JIT) code that works with OCaml 3.10, it'd probably have to be adapted for 3.12: http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/OcamlGCPrinter.cpp http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/OcamlGC.cpp http://llvm.org/releases/2.8/docs/GarbageCollection.html > > LLVM is nice and trendy It'd be even nicer if it was written in OCaml, whenever I write C++ code lately it feels like I could've written the same with much less code in OCaml. If someone were to develop an LLVM backend for OCaml, I think it could coexist with ocamlopt though, allowing the user to choose which backend it wants to use. > (though it's a shame the GNU guys, partly due > to their own mistakes, are losing an important part of the FLOSS > ecosystem to Apple...), Well there could also be a GCC backend for OCaml, but I don't know how one should get started writing one (or if it would be worth it). Best regards, --Edwin