Re: [Caml-list] LLVM OCaml bindings

[Jeff Meister <nanaki@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4747 bytes --]

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.

- Jeff


On Tue, Nov 5, 2013 at 3:32 AM, Peter Zotov <whitequark@whitequark.org>wrote:

> Jacques-Pascal Deplaix писал 05.11.2013 15:09:
>
>> Hi,
>>
>>
>> So now I have again my own binding that produces LLVM-IR but this time
>> with the same interface than the official binding, and it works pretty
>> well [4].
>>
>
> The problem is that just generating LLVM IR is often not enough.
> All of the below cannot be achieved without a proper binding:
>
> 1) JIT,
> 2) Querying the backend for sizes of structures, legal integral types,
> 3) Native code generation without shelling out.
>
> Generally, you can do very much with LLVM by shelling out to its plenthora
> of command-line tools, but I find the in-process solution cleaner.
>
> You can get sensible error messages instead of segfaults by using
> a Debug+Asserts or Release+Asserts build of LLVM. The builds packaged
> in Debian, opam, etc are usually built without asserts.
>
> I'll probably release LLVM 3.4 bindings on opam and they will feature
> asserts on by default.
>
>
>  [2]: I have done several issues on the LLVM bug tracker, but apart from
>> segfaults and bugs when trying to use LLVM_bitwriter, the missed feature
>> is, IMHO, the possibility to get a string that contains the LLVM-IR
>> code, and not just print it.
>>
>
> This will be included in upcoming 3.4 release. I will be happy to hear
> (and likely implement) what else do you miss.
>
>
>  [3]: https://github.com/jpdeplaix/cervoise/blob/jeSuisFou/src/LLVM.mli
>> [4]: https://github.com/jpdeplaix/cervoise/blob/master/src/LLVM.ml
>>
>> On 11/05/2013 05:23 AM, Peter Zotov wrote:
>>
>>> Hello folks,
>>>
>>> I'm currently working on improving LLVM's OCaml bindings.
>>> There's been quite some progress so far[1]; the only major
>>> areas pending are AOT code generation and MCJIT support.
>>>
>>> I would be very interested to hear how are you using these
>>> bindings, or suggestions for future development. In particular,
>>> I'd like to understand the impact of breaking the API.
>>>
>>>   [1]: https://github.com/llvm-mirror/llvm/commits/master/bindings/ocaml
>>>
>>>
> --
>   WBR, Peter Zotov.
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 6416 bytes --]