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. 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, 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.

- 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.

LLVM is nice and trendy (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...), but I'm personally more interested in the more theoretical
projects of  verified compilation toolchains, such as compcert (
http://compcert.inria.fr/ ). It's unrealistic to hope to have a completely
verified ocaml-to-assembly compiler, as we would first need formal semantics
for the OCaml language itself, but it is the very point : doing that kind of
things forces you to have formal semantics, which is very interesting in
many respects.

Asking for a decent compiler was once the way to tell apart the serious
languages from the insane string-fiddling script languages, but the line is
blurred by the indecent amount of work injected in the optimization of those
insane languages. Formal semantics will distinguish the gentlemen of the
future.