[LLVMdev] improving the ocaml binding's type safety
gordonhenriksen at mac.com
Sat Mar 15 08:49:37 PDT 2008
On 2008-03-15, at 10:09, Jon Harrop wrote:
> There is an overhead in building these intermediate data structures
Converting enums to tags, yes. Phantom types no.
> 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
You're reinventing the object model here. There's no reason you
shouldn't build your own IR separate from LLVM's, though. Just write
an output algorithm to convert your IR into an llmodule using the
bindings so you can interoperate with the LLVM infrastructure.
> 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.
LLVM doesn't use exceptions. assert() failures just print to stderr
and call abort() [= exit(1)], so they can't be caught. Even if they
could, the stack couldn't be unwound (because the C++ exception tables
are not emitted), so the program would leak memory and leave leave the
heap in inconsistent state, inevitably leading to crashes. So this
isn't going to happen.
I'm not disputing that this is a pain point, however. I wouldn't be
opposed to patches which check preconditions in the ocaml bindings
layer and raise exceptions before calling into the C bindings.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev