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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id B3702BC57 for ; Tue, 30 Nov 2010 18:29:24 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIBAO/C9EzRVde0k2dsb2JhbACVB44ECBUBAQEBCQkKCREDH6l5i3wBBY5EAQSCE4M0 X-IronPort-AV: E=Sophos;i="4.59,281,1288566000"; d="scan'208";a="68872334" Received: from mail-ey0-f180.google.com ([209.85.215.180]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Nov 2010 18:29:24 +0100 Received: by eyf18 with SMTP id 18so2678184eyf.39 for ; Tue, 30 Nov 2010 09:29:23 -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=ZNMe04j8RkeDgSuOT+dhvuemR4aEppIFGnArjJYBoWY=; b=wyw11xS+DQ0hhDFtDdjsXNtnUJuJM1r+351Zcw95yAJnt092oVnrKW6LcIlkTerf8a YW0xO4tQgbNMGfirp1RjzwVr8Ymgxq3ItWVmRHfRrlRHtnnVXIcXYIS5Lzv03bWfXfas 4V1gRR3XJjUgRhQNBje0exfVSek5TaP/8Yu1M= 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=GrUFplUIrLeoQWhZ4yCwHxH/dAB8WSg3dPP5qUblnPX+oO/XoTx9o2ilof/1C62Y2k blBKTha6q6+Hx5qEw4EV1ENXZOKe+Jxf1COoPKfyGCO7gpvErLItSYRcd9qkOecXE2A1 nh+F7ywRs0GzoZ9Y7rnSJM79e3iXYUbnRXnv0= Received: by 10.213.6.193 with SMTP id a1mr1403723eba.94.1291138163606; Tue, 30 Nov 2010 09:29:23 -0800 (PST) Received: from bespin.kosmos.all (ip-95-223-170-32.unitymediagroup.de [95.223.170.32]) by mx.google.com with ESMTPS id v56sm6556948eeh.8.2010.11.30.09.29.22 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Nov 2010 09:29:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: [Caml-list] OCamlJIT2 vs. OCamlJIT From: Benedikt Meurer In-Reply-To: Date: Tue, 30 Nov 2010 18:29:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <70841487-61C0-417F-A446-EA9B47738676@googlemail.com> References: <3DCEA910-1382-47E5-876B-059178F8F82E@googlemail.com> <20101130124803.7952fca1@deb0> To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; ocaml:01 bytecode:01 ocaml:01 compiler:01 ocamlopt:01 compiler:01 non-trivial:01 runtime:01 bytecode:01 runtime:01 segv:01 integers:01 non-trivial:01 pointers:01 garbage:01 On Nov 30, 2010, at 18:01 , bluestorm wrote: > - more portability : while I'm not sure LLVM is ported to more = platforms than OCaml right now, the LLVM community will probably port = its bytecode to numerous architectures in the future; in contrast, = maintining numerous backend in the OCaml compiler has a maintainance = cost. In particular, cross-compilation would probably be easier. Indeed, cross-compilation would be a nice benefit. > - 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.=20 Most of LLVM optimizing passes won't help with OCaml, as they are = targeted towards constructs generated by C/C++/Java compilers. Of course = that could be fixed to include constructs generated by the OCaml = compiler, but we won't get much for free here. > 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. This is a major issue, which also hit me with the bytecode runtime. In = the native runtime it's even worse; there is no well-defined stack = layout nor specific register assignment in LLVM, necessary to handle the = runtime and garbage collector calls. One would need to reinvent the = OCaml runtime and GC interface (at least in part) to fit well with LLVM. = Some of this can be fixed using special calling conventions, but that = way the problems are simply shifted down to another layer (requiring = more - possibly not really portable - changes to LLVM). You will be = faced with various small issues, like how to check whether a SEGV was = caused within OCaml code (for stack overflow detection), how to force = LLVM to place only tagged integers onto the C stack when spilling = registers, etc. Resolving these issues will require various non-trivial = changes to both OCaml and LLVM. Studying GHC-LLVM might help to resolve = some of them (i.e. there is already a GHC calling convention available = in LLVM); maybe the Mono-LLVM backend may also provide some pointers. Benedikt=