Re: [Caml-list] OCamlJIT2 vs. OCamlJIT

[Benedikt Meurer <benedikt.meurer@googlemail.com>]

On Nov 30, 2010, at 18:01 , bluestorm wrote:

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

Indeed, cross-compilation would be a nice benefit.

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

Most of LLVM optimizing passes won't help with OCaml, as they are targeted towards constructs generated by C/C++/Java compilers. Of course that could be fixed to include constructs generated by the OCaml compiler, but we won't get much for free here.

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

This is a major issue, which also hit me with the bytecode runtime. In the native runtime it's even worse; there is no well-defined stack layout nor specific register assignment in LLVM, necessary to handle the runtime and garbage collector calls. One would need to reinvent the OCaml runtime and GC interface (at least in part) to fit well with LLVM. Some of this can be fixed using special calling conventions, but that way the problems are simply shifted down to another layer (requiring more - possibly not really portable - changes to LLVM). You will be faced with various small issues, like how to check whether a SEGV was caused within OCaml code (for stack overflow detection), how to force LLVM to place only tagged integers onto the C stack when spilling registers, etc. Resolving these issues will require various non-trivial changes to both OCaml and LLVM. Studying GHC-LLVM might help to resolve some of them (i.e. there is already a GHC calling convention available in LLVM); maybe the Mono-LLVM backend may also provide some pointers.

Benedikt