[LLVMdev] improving the ocaml binding's type safety

Jon Harrop jon at ffconsultancy.com
Sat Mar 15 07:09:37 PDT 2008

For all LLVM users out there: what kinds of errors do you spend the most time 

On Saturday 15 March 2008 08:03:47 Erick Tryzelaar wrote:
> Does this sound like it could work, or am I missing something?

Excellent idea. You might also consider building a data structure on the OCaml 
side that is equivalent to the LLVM code:

  module Op = struct
    type int_op = [ `IAdd | ... ]
    type float_op = [ `FAdd | ... ]
    type bool_op = [ `ILe of int_op * int_op | ... ]
    type t = [ int_op | float_op | bool_op | ... ]

Now you have int_op and bool_op as subtypes of Op.t.

Note that neither of these approaches can be as expressive as using GADTs 
which, I assume, is what the Haskellers have done. On the other hand, this 
will probably catch errors that people don't make anyway (hence my opening 

There is an overhead in building these intermediate data structures but I 
expect it will be insignificant. You also have the advantage that you can 
print out the blocks that will be passed to LLVM.

There are other errors that you can catch using a static type system as well. 
Several ops can only appear either at the start (e.g. phi node) or end (e.g. 
unconditional branch) of a block. These should be taken out of the set of 
general ops and blocks should have different types of start and end:

  module Block = struct
    type start = [ `None | Phi of ... ]
    type end = [ `Return of Op.t | `Branch of Block.t ref ]
    type t = start * Op.t list * end

Another practical advance I'd like to see is the LLVM bindings catching 
exceptions on the C++ side and reraising them in OCaml. At the moment you 
cannot get a stacktrace from an OCaml program that dies due to an exception 
being raised in LLVM which is a bit frustrating because you have to guess 
where the program died in the OCaml code.

Still, this is all good stuff and I believe OCaml and LLVM have a rosy future 
together. :-)

Dr Jon D Harrop, Flying Frog Consultancy Ltd.

More information about the llvm-dev mailing list