English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Ocamlopt code generator question
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-05-05 (15:07)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Ocamlopt code generator question
On Tuesday 05 May 2009 15:15:33 Jean-Marc Eber wrote:
> Hi Dimitry,
> LexiFi for instance _is_ clearly interested by a sse2 32bit code generator.
> One should probably have the following in mind and/or ask the following
> questions:
> - it is probably not a good idea to support both backends (sse2 and old
> stack fp i386 architecture). It will be necessary to make a choice
> (especially taking in account the limited INRIA resources and the burden of
> already supporting different windows ports).
> - would INRIA be ok to switch to a sse2 code generator (based on Dimitry's
> patch - supposing that he is ok to donate it to INRIA - or Xavier's work or
> whatever)?
> - I also guess that a sse2 code generator would be simpler than the current
> one (that has to support this horrible fp stack architecture) and would
> therefore be a better candidate for further enhancements.
> - what is the opinion on this list, as a switch to a sse2 backend would
> exclude "old" processors from being OCaml compatible (I don't have a
> precise list at hand for now) ?
> My opinion is that this support of legacy hardware is not important, but I
> guess others are arguing in opposite directions... :-)
> But again, having better floating point performance (and predictable
> behaviour, compared to the bytecode version) would be a big plus for some
> applications.

If the idea is to provide better code generation on x86 going forwards with 
minimal effort then I'd have thought an LLVM-based backend would be the 
obvious choice. My tests with HLVM showed that numerical code can be a 
whopping 8x faster than today's ocamlopt on x86 and, of course, LLVM is 
improving much more rapidly.

LLVM can probably replace the x86, x64 and ppc backends. LLVM also seems like 
a sane approach to providing a native-code top level via its existing JIT 

Dr Jon Harrop, Flying Frog Consultancy Ltd.