Re: [Caml-list] Google summer of Code proposal

[Jon Harrop <jon@ffconsultancy.com>]

On Saturday 21 March 2009 13:47:40 Andrey Riabushenko wrote:
> > > LLVM
> > > will give ocaml an aggressive whole program optimizer and will make
> > > possible to run ocaml on new platforms that are supported by LLVM, but
> > > not yet by Ocaml.
> >
> > Is there any such platform?
>
> There are - PIC16, XCore, Cell SPU and Microsoft IL (F# reinvented :).
> Many others are under development.

Both OCaml and LLVM support x86, x64 and ARM as well as having backends for 
many other architectures that are of questionable quality. For example, 
LLVM's CIL backend was broken when I tried it and, of course, it cannot even 
support generics because LLVM is incapable of expressing parametric 
polymorphism. For OCaml, there is OCamIL for generating CIL but it also does 
not support parametric polymorphism because it is for .NET 1.1.

I have been developing with LLVM for many months now and I have had two main 
gripes:

1. LLVM calls abort() instead of raising an exception and that makes it almost 
impossible to debug LLVM code because it just dies immediately upon hitting 
any error and gives only the most convoluted contextless error messages. The 
best solution I have found is to litter your LLVM IR emitter with debug 
printfs. HLVM overcomes this problem by catching and handling type errors 
appropriately, making it much easier to use.

2. Many of LLVM's features sound alluring but turn out to be unusable. 
Fortunately, the two core features required to support languages like OCaml 
robustly and efficiently (tail calls and first-class structs) are almost 
completely working. Most of HLVM's development effort has gone into rejecting 
or working around features that do not work correctly in LLVM.

Just to give some examples:

. I found that LLVM's x86 backend breaks tail calls when the return type is a 
first class struct. The workaround is to use sret form, having the caller 
preallocate the return struct and passing a pointer to the struct as an extra 
first argument.

. Lennart Augustsson found that LLVM's vector intrinsics can generate broken 
SSE code for 2D vectors. There is no general workaround: you are expected to 
special-case this situation in all front-ends (!).

. Many people have written to me because they have been unable to get LLVM's 
GC API to work at all. Upon hearing the issues, I immediately opted to use a 
shadow stack designed for an uncooperative environment in HLVM. This at least 
works but it is needlessly inefficient.

. OCaml is vastly superior to C++ for writing compilers but the OCaml bindings 
to LLVM are far from complete. HLVM includes its own auxiliary bindings for 
many important features such as first-class structs and enabling tail calls.

LLVM is a great tool and a wonderful opportunity but it is not a panacea and 
it would be wise to learn such lessons before jumping in to LLVM-based 
development.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e