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 6591EBC57 for ; Sun, 12 Dec 2010 20:56:00 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AACa3BE3RVaEtimdsb2JhbACDW6AiCBUBAQsJDAcPBiWmOok0PIIYg3cuiFYBAQMFgRyDNXQEhR6JVw X-IronPort-AV: E=Sophos;i="4.59,333,1288566000"; d="scan'208";a="70357369" Received: from mail-fx0-f45.google.com ([209.85.161.45]) by mail3-smtp-sop.national.inria.fr with ESMTP; 12 Dec 2010 20:55:59 +0100 Received: by fxm12 with SMTP id 12so5610487fxm.4 for ; Sun, 12 Dec 2010 11:55:59 -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=gjLJX4K7lKsMD/n5ijX6CXOiw/hGBMel0wJEm+0X/9c=; b=jrGjTvypVH5fOpLVYTh+auTyRCWxUVkpalUpuMc6tQd4JGyHtZFp34sjiViMOXlV3O LHqEKq2PG8WBXtEtioCi4I2H2Y5ookQZWkDKVRCJAyu90lXhBKT/xq0dldBJJbCFTg2w 0ykA+pdzv2tzWmZtUOXwUg5w7suElyBH5ldDU= 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=QTkTPm2rZH05IvdEh8D7Yy+mVHmTdZU3rVcJBb8ocSkJSugwCJP13TYr5VrsrAFQaT ZfdlW3vjgtuvBkAI2vvbanZBkqkgNU0qVNlkKt1ubSlZRat0Iq4ZL1vu8/9Vgscf++Oi 7UbrCVs5SVej3Xz+sMwZ2sqkFqeSSTbPn38ww= Received: by 10.223.107.9 with SMTP id z9mr3318148fao.148.1292183759497; Sun, 12 Dec 2010 11:55:59 -0800 (PST) Received: from deb0 ([79.114.96.209]) by mx.google.com with ESMTPS id 5sm1498037fak.23.2010.12.12.11.55.58 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Dec 2010 11:55:59 -0800 (PST) Date: Sun, 12 Dec 2010 21:55:52 +0200 From: =?UTF-8?B?VMO2csO2aw==?= Edwin To: Benedikt Meurer Cc: caml-list@yquem.inria.fr Subject: Re: Value types (Was: [Caml-list] ocamlopt LLVM support) Message-ID: <20101212215552.317892e7@deb0> In-Reply-To: <9264BEE6-DBAE-4523-93AC-4560615D2AC5@googlemail.com> References: <036001cb9a0c$725acef0$57106cd0$@com> <20101212175524.73a8e285@deb0> <9264BEE6-DBAE-4523-93AC-4560615D2AC5@googlemail.com> 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocamlopt:01 compiler:01 'int:01 ocamlopt:01 int's:01 nativeint:01 high-level:01 runtime:01 inlined:01 overkill:01 runtime:01 bindings:01 low-level:01 ocaml:01 haskell:01 On Sun, 12 Dec 2010 20:09:00 +0100 Benedikt Meurer wrote: >=20 > On Dec 12, 2010, at 16:55 , T=C3=B6r=C3=B6k Edwin wrote: >=20 > > [...] > > Problem #2: Int64.div n 2 -> idiv instruction.=20 > >=20 > > A C compiler would optimize this to a right shift. Changing that to > > 'Int64.shift_right n 1' speeds up the code. >=20 > This is easy to fix in ocamlopt (see attached patch > ocamlopt-natint.patch), by applying the same optimizations already > used for constant int's to constant natint's (Int64 is Nativeint on > 64bit). Nice patch. I definitely agree that what can be fixed in ocamlopt's high-level opts should be fixed there, rather than hope that LLVM will just do everything. > [...] > >=20 > > One advantage of using LLVM is that it would notice arithmetic > > optimizations like this and perform it itself (even if you use the > > boxed representation). >=20 > In case of x86-32, it won't, simply because LLVM will be presented > with the calls to caml_int32_* functions.=20 I was thinking that the runtime could be compiled to .bc, and then they would get inlined and optimized away at link time. That is overkill for something as simple as integer arithmetic, but could be useful for more complicated runtime functions (or C bindings). > You'd need to change the > Cmm code instead (changing the low-level stuff is straight-forward as > demonstrated). I agree that not emitting those C calls in the first place is better. > For 64bit targets, see attached patch. >=20 > This doesn't mean that LLVM wouldn't be useful (in fact, I've just > started an LLVM backend for ocamlopt). Great! If you notice some more optimizations missed by ocamlopt while working on it, could you write up a list of those? I think I suggested earlier in this thread that LLVM could be used in two ways: write a backend with it, or port some of the LLVM optimizations to ocamlopt. Maybe it'd be good to write some documentation on ocamlopt's internals, and how one can add more optimizations there. Something simple like what is the IR format (like LLVM's langref), how you perform the optimizations (what is the equivalent of LLVM's passes), and what helper modules can you use (what is the equivalent of LLVM's analysis) would suffice for a start. Does something like this exist already? > But it is important to note > that LLVM is not the solution to everything. As the name implies, > it's "low level", it does a few "higher level" optimizations for C, > but these are special cases (and somewhat ugly if you take the time > to read the code). It won't make a faster OCaml magically, just like > it didn't make a faster Haskell by itself. >=20 > I could go on by quoting common "Harrop jokes" like "you need types > in the low-level IR", etc. trying to tell him that this is simply > wrong; but after reading through the Caml/LISP mailing list archives > (thanks for the pointers by several readers), I'm pretty much > convinced that Jon simply decided to end his war against LISP just to > start a new one against ocamlopt. >=20 > If anyone is serious about ocamlopt with LLVM, feel free to contact > me (tho, my time is limited atm). I wouldn't have much time to dedicate to this, so I can't say I'm serious about it.=20 AFAICT LLVM's OCaml bindings are only good for generating LLVM IR from OCaml, not for actually performing transformations on it (there is no binding to retrieve the type of a value for example). I'll probably be looking into fixing that in the near future, and this may indirectly help your LLVM backend (if you intend to write OCaml specific transformations on the LLVM IR). Best regards, --Edwin