[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
debugging?
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 | ... ]
end
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
question).
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
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.
http://www.ffconsultancy.com/products/?e
More information about the llvm-dev
mailing list