Re: [Caml-list] OCamlJIT2 vs. OCamlJIT

["Török Edwin" <edwintorok@gmail.com>]

On Tue, 30 Nov 2010 18:01:28 +0100
bluestorm <bluestorm.dylc@gmail.com> 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