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

[Jon Harrop <jon@ffconsultancy.com>]

On Saturday 21 March 2009 12:39:45 Andrey Riabushenko wrote:
> Hi OCaml hackers,
>
> It is not mistake, in spite of ocaml does not take part in GSoC 2009, but
> ocaml community still can benefit from it.
>
> I would like to develop LLVM frontend to Ocaml language. LLVM  does
> participate in GSoC. LLVM do not mind to developed a ocaml frontend as LLVM
> GSoC project. I want to discuss details with you before I will make an
> official proposal to LLVM.

I recommend you peruse the LLVM and HLVM mailing lists for information about 
current work along similar lines:

  http://hlvm.forge.ocamlcore.org

> 1. What is the best way to make ocaml frontend on your opinion?

The impedance mismatch between the current OCaml compilers and LLVM is high:

. The OCaml compilers remove type information in the early stages of 
compilation but LLVM is a typed assembler and needs that information to be 
conveyed all the way through to the back end.

. The OCaml compilers make no attempt to provide reusable intermediate 
representations.

So you will probably end up hacking extensively on ocamlopt's internals and, 
consequently, your code will be bound by the QPL license even though you will 
probably not salvage much. This is why I started from scratch.

> I think the best would to way to develop ocaml llvm front end as a part of
> ocaml distribution. I don't not want to develop yet another a separate
> project, which is half-done llvm frontend that nobody uses. There are
> plenty of those for other languages lying around. I propose to forget about
> JIT capabilities of LLVM and concentrate on AOT compilation for now.

JIT is the single most important benefit of LLVM in the context of OCaml. With 
JIT:

. You can instantiate polymorphic definitions for each combination of type 
parameters that they are used with, providing substantial performance 
improvements.

. You can generate code that is optimized for the current machine.

. You can provide a performant top-level.

Forgetting about JIT would certainly be a mistake.

> Ocamlopt currently generates native assembler for the following platforms:
> i386, AMD64, ia64, arm, hppa, alpha, m68k, mips, powerpc, sparc assembler.
> I propose to add LLVM assembler generation as another platform to ocamlopt.
> It requires the least modification of ocaml source and easy to maintain.

There are many problems with this:

. You will succumb to ocamlopt's current run-time representation which is 
objectively inefficient (e.g. boxing floats, tuples, records) and was only 
chosen because the compiler lacks capabilities that LLVM already provides for 
you (primarily JIT compilation).

. LLVM's optimization passes will not optimize the representations and, 
consequently, performance will not be improved.

. You will inherit ocamlopt's most serious flaws: its run-time and its FFI.

. If you inherit ocamlopt's run-time then you will need to be able to generate 
compliant code from LLVM which is extremely difficult, error prone and almost 
entirely untested.

> LLVM will give ocaml an aggressive whole program optimizer...

I doubt you could even match the performance of OCaml's existing compiler with 
that approach, much less beat it. There are two reasons for this:

. Building upon ocamlopt's internal run-time representation (e.g. boxed 
tuples) ties LLVM's hands behind its back when it comes to optimization. LLVM 
could do very little to optimize such code.

. LLVM's existing optimization passes work great on naively-generated C or C++ 
code but they know nothing about parametric polymorphism, closures and 
pattern matching. These high-level language features are where the most 
beneficial optimizations lie.

For example, applying LLVM's optimization passes to HLVM generated code only 
give ~15% performance improvements.

> Question to the Ocaml creators and maintainers.
>
> 2. Will you merge LLVM platform to the ocaml trunk assuming that it works
> as it should?

Collaboration with the existing HLVM effort would probably be far more 
productive.

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