Hi Peter,
I did some work on the LLVM OCaml bindings back in grad school. Basically, I tried to fix the segfault issue that Jacques-Pascal mentioned above. The problem (well, one problem at least) is that LLVM's OCaml bindings operate through a C interface which is not type safe with respect to the underlying LLVM C++ implementation. For example, in llvm.mli we have:
val const_int : lltype -> int -> llvalue
val build_call : llvalue -> llvalue array -> string -> llbuilder -> llvalue
I can call const_int to get an llvalue representing an integer, then pass this llvalue as the first argument to build_call, which expects a function. Since both have type llvalue, the OCaml type checker will not complain, but a segfault or other undefined behavior will likely result at runtime.
What I did to fix this was reintroduce the inheritance hierarchy present in the C++ code. Using some module system tricks to make OCaml's structural subtyping act like nominal subtyping, I refactored everything into classes. In my version, const_int would return a ConstInt.t, which is a subtype of Value.t, but not compatible with the Function.t required by build_call.
There are two reasons why I never publicly released my code. First, I haven't kept up with the last couple years of changes to the LLVM API, so it's probably not in a usable state right now. Second, OCaml subtyping is kind of a pain in the ass, and I wasn't sure whether people would want it. To pass a ConstInt.t into any method that expects a supertype requires an explicit cast, and the C++ structure of LLVM results in quite a lot of these casts. The cost of type-safe LLVM bindings is extra verbosity.
However, there is a branch in the OCaml svn that would eliminate almost all of this cost: the implicit_subtyping branch. In that branch, if I'm passing a ConstInt.t to a function with a type annotation expecting Value.t, OCaml will try to perform the upcast for me, and proceed if it works. I played with this branch back when I was working on the bindings, and it made things much more pleasant. I'm not sure of the status of this branch, or whether the INRIA folks plan to integrate it into mainline at some point.
I will try to find my code and put it up on GitHub if it would be useful to you.