[LLVMdev] improving the ocaml binding's type safety

[Gordon Henriksen]

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

— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080315/07696bd8/attachment.html>