[Caml-list] LLVM OCaml bindings

[Caml-list] LLVM OCaml bindings

[Peter Zotov]

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.

Re: [Caml-list] LLVM OCaml bindings

[Gabriel Kerneis]

On Tue, Nov 05, 2013 at 08:23:55AM +0400, Peter Zotov wrote:
> 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.

On a slightly unrelated note, do you also plan to work on CLANG (e.g. libclang)
bindings?

Best regards,
-- 
Gabriel

Re: [Caml-list] LLVM OCaml bindings

[Peter Zotov]

Gabriel Kerneis писал 05.11.2013 12:12:
> On Tue, Nov 05, 2013 at 08:23:55AM +0400, Peter Zotov wrote:
>> 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.
> 
> On a slightly unrelated note, do you also plan to work on CLANG (e.g. 
> libclang)
> bindings?

I do not have concrete plans yet, but I will likely need such bindings
in the future.

-- 
   WBR, Peter Zotov.

Re: [Caml-list] LLVM OCaml bindings

[Jacques-Pascal Deplaix]

Hi,

I'm using LLVM for the compiler of my toy language Cervoise (link below).

First, before I started it, I heard from a friend that the official LLVM
binding can segfaults so I didn't want to use it [1].

I tried to create my own binding that produces LLVM-IR but there were
bugs (the interface didn't seems good).

So I tried the official binding. Like expected, it segfaults and has
several bugs and misses features [2] :/

Then, I tried to reproduce the interface of the LLVM binding but with
types parameters for lltype and llvalue to know what LLVM types can be
inserted for a function (the main cause of segfault), but it was very
very painful since we have to separate impossible cases and the type
errors (with recursive polymorphic variants) are awesome (irony) [3].

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

As a conclusion, don't try to add a type parameter like I did (however,
you can try other ways), it would be a waste of time.

[1]: We tried to fix this by starting TyLLVM (but it's not satisfying
and far to be finished): https://bitbucket.org/dinosaure/tyllvm
[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.
[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
>

Re: [Caml-list] LLVM OCaml bindings

[Peter Zotov]

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.

Re: [Caml-list] LLVM OCaml bindings

[Jeff Meister]

[-- 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 --]

Re: [Caml-list] LLVM OCaml bindings

[Peter Zotov]

Jeff Meister писал 06.11.2013 01:00:
> 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.

As mentioned elsewhere, it's defined in Asserts build. Personally,
I'm going to ship my compiler with LLVM built in Release+Asserts mode.

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

One thing to consider is that the C++ API does not use subtyping for
this kind of safety, either. Consider the prototype of
IRBuilder::CreateCall:
CallInst *CreateCall (Value *Callee, ArrayRef< Value * > Args, const 
Twine &Name="")

This means that there is no guarantee you can convert the API to use
the subtyping safety measure you devised. Indeed, there are several
functions which do not have an equivalent type in hierarchy.
Llvm.set_volatile expects a [load] or [store], where Llvm.set_alignment
expects a [load], [store] or a global value, and 
Llvm.set_atomic_ordering
expects a [load], [store], [atomicrmw], [fence], or [cmpxchg].
LLVM itself represents this by trying to explicitly cast the 
instruction
to each supported one, and then calling the corresponding method.

Interestingly, this kind of relationship can be expressed better by 
OCaml's
structural OO system than C++'s nominative one. I think that a project
to wrap either LLVM's C or C++ API into OCaml's classes and objects may
be a good solution to at least part of the problem. I don't have time
to develop this myself, though.

> I will try to find my code and put it up on GitHub if it would be 
> useful to you.

I would be interested to look into it, but I probably will not 
integrate
it into the bindings.

-- 
   WBR, Peter Zotov.

Re: [Caml-list] LLVM OCaml bindings

[Jeff Meister]

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

On Tue, Nov 5, 2013 at 11:19 PM, Peter Zotov <whitequark@whitequark.org>wrote:

> Jeff Meister писал 06.11.2013 01:00:
>
>  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.
>>
>
> As mentioned elsewhere, it's defined in Asserts build. Personally,
> I'm going to ship my compiler with LLVM built in Release+Asserts mode.
>

Sure, but those are runtime assertions, not compile time type errors. In my
opinion, if the correct types can be expressed in OCaml, we should use
them. Collapsing LLVM's complex subtype hierarchies into types like llvalue
and lltype is not acceptable to me as an OCaml programmer. I might as well
program in C.


> 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.
>>
>
> One thing to consider is that the C++ API does not use subtyping for
> this kind of safety, either. Consider the prototype of
> IRBuilder::CreateCall:
> CallInst *CreateCall (Value *Callee, ArrayRef< Value * > Args, const Twine
> &Name="")
>
> This means that there is no guarantee you can convert the API to use
> the subtyping safety measure you devised. Indeed, there are several
> functions which do not have an equivalent type in hierarchy.
> Llvm.set_volatile expects a [load] or [store], where Llvm.set_alignment
> expects a [load], [store] or a global value, and Llvm.set_atomic_ordering
> expects a [load], [store], [atomicrmw], [fence], or [cmpxchg].
> LLVM itself represents this by trying to explicitly cast the instruction
> to each supported one, and then calling the corresponding method.
>
> Interestingly, this kind of relationship can be expressed better by OCaml's
> structural OO system than C++'s nominative one. I think that a project
> to wrap either LLVM's C or C++ API into OCaml's classes and objects may
> be a good solution to at least part of the problem. I don't have time
> to develop this myself, though.
>

That's a very interesting point! In my implementation, I simply duplicated
the C++ method types, so if a parameter had type Value in C++, the same was
reflected in the OCaml interface, even if the actual type is more complex
as you described. My goal was simply to get the OCaml bindings on par with
the C++ types to prevent undefined behavior (or runtime assertion failures)
from mistaken casts that can easily be detected statically in OCaml. If we
could use the OCaml type system to go even further than C++, that would be
excellent!


>  I will try to find my code and put it up on GitHub if it would be useful
>> to you.
>>
>
> I would be interested to look into it, but I probably will not integrate
> it into the bindings.
>
>
> --
>   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: 4916 bytes --]

Re: [Caml-list] LLVM OCaml bindings

[Jacques-Pascal Deplaix]

Why LLVM chose to do Asserts instead of raise an exception ?
Anyways, thanks for your impressive work. I will consider re-switch to
the official binding if it's finally usable.

On 11/05/2013 12:32 PM, Peter Zotov 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
>>>
>

Re: [Caml-list] LLVM OCaml bindings

[Peter Zotov]

Jacques-Pascal Deplaix писал 06.11.2013 01:30:
> Why LLVM chose to do Asserts instead of raise an exception ?
> Anyways, thanks for your impressive work. I will consider re-switch to
> the official binding if it's finally usable.
> 

Several reasons.

1) C++ exceptions are very costly in terms of space (RTTI), and also in
    terms of time when they're raised. LLVM, striving to be efficient,
    uses neither exceptions nor RTTI.

2) Writing exception-safe C++ code can be very tricky: essentially, one
    needs to make all data structures transactional and ensure that
    any control-flow path, whether it involves exceptions or not, leaves
    them in a valid state.

3) LLVM has about seven thousand assertions. The amount of code 
required
    to gracefully handle all that with exceptions is huge, and since
    asserts most of the time test for conditions presumed impossible,
    how do you test those codepaths?

I agree that an error handling strategy better than puts();abort() 
would
be nice, but I cannot see LLVM using exceptions, either.

-- 
   WBR, Peter Zotov.

RE: [Caml-list] LLVM OCaml bindings

[Jon Harrop]

I just wanted to check: you're not breaking the existing bindings, right?

-----Original Message-----
From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Behalf Of Peter Zotov
Sent: 05 November 2013 04:24
To: caml-list@inria.fr
Subject: [Caml-list] LLVM OCaml bindings

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

RE: [Caml-list] LLVM OCaml bindings

[Peter Zotov]

Jon Harrop писал 08.11.2013 13:36:
> I just wanted to check: you're not breaking the existing bindings, 
> right?

Sorry, realized the previous letter was phrased ambiguously.
I'm asking because I do want to break existing bindings. The changes 
would
mainly touch two areas:
1) Memory management. I want to get rid of most or all of dispose 
functions
and allow to use OCaml's GC.
2) Llvm_target interface is very outdated and it could be updated to 
integrate
much better with the TargetMachine interface.

There are also two or three Llvm functions which need minor changes.

I'm not going to change APIs in any way which needs nontrivial, 
significant
fixes to clients, there's simply no need.

-- 
   WBR, Peter Zotov.

RE: [Caml-list] LLVM OCaml bindings

[Jon Harrop]

> I'm not going to change APIs in any way which needs nontrivial, significant fixes to clients, there's simply no need.

Ok, great.

Jeff Meister was talking about writing more type safe bindings. I think that would be fine as long as it wraps the existing less-safe bindings so people can continue to use them. I tried using LLVM from Haskell and had a lot of problems because they'd used every trick in the book to write the most type safe possible bindings and it makes it much harder to learn and use. I'd personally much rather see more complete bindings...

BTW, what are your thoughts on MSJIT? I just started reading about it and it seems very underwhelming. Sounds like they're struggling to refactor their C++ code so they're reinventing things but not doing it significantly better. So I don't think I'll be rushing to switch to MSJIT unless they actually deprecate the old JIT.

Cheers,
Jon.

-----Original Message-----
From: Peter Zotov [mailto:whitequark@whitequark.org] 
Sent: 08 November 2013 10:19
To: jon@ffconsultancy.com
Cc: caml-list@inria.fr
Subject: RE: [Caml-list] LLVM OCaml bindings

Jon Harrop писал 08.11.2013 13:36:
> I just wanted to check: you're not breaking the existing bindings, 
> right?

Sorry, realized the previous letter was phrased ambiguously.
I'm asking because I do want to break existing bindings. The changes would mainly touch two areas:
1) Memory management. I want to get rid of most or all of dispose functions and allow to use OCaml's GC.
2) Llvm_target interface is very outdated and it could be updated to integrate much better with the TargetMachine interface.

There are also two or three Llvm functions which need minor changes.

I'm not going to change APIs in any way which needs nontrivial, significant fixes to clients, there's simply no need.

-- 
   WBR, Peter Zotov.

RE: [Caml-list] LLVM OCaml bindings

[Peter Zotov]

Jon Harrop писал 08.11.2013 15:31:
>> I'm not going to change APIs in any way which needs nontrivial, 
>> significant fixes to clients, there's simply no need.
> 
> Ok, great.
> 
> Jeff Meister was talking about writing more type safe bindings. I
> think that would be fine as long as it wraps the existing less-safe
> bindings so people can continue to use them. I tried using LLVM from
> Haskell and had a lot of problems because they'd used every trick in
> the book to write the most type safe possible bindings and it makes it
> much harder to learn and use. I'd personally much rather see more
> complete bindings...

I completely agree. I don't currently know if I will write type-safe
bindings (if I do, they'll be based on OCaml's OO... it's a nearly
perfect match for the kind of API LLVM has), but they'll be
based on the low-level bindings, not replace them.

By the way, I'm currently in process of upstreaming all extensions for
the C API the Haskell (llvm-general) bindings internally have.

> 
> BTW, what are your thoughts on MSJIT? I just started reading about it
> and it seems very underwhelming. Sounds like they're struggling to
> refactor their C++ code so they're reinventing things but not doing it
> significantly better. So I don't think I'll be rushing to switch to
> MSJIT unless they actually deprecate the old JIT.

MCJIT is a great idea in general, since it reuses much more of the
LLVM infrastructure, in particular the MC layer, so you don't have two
different code generators to maintain. Right now it's very incomplete
and I won't use it yet. There seems to be a moderate interest in
a better MCJIT so I hope it becomes much more usable in the next
few months.

As I understand it, the old JIT is already deprecated, it's just not
removed yet (and will not be for a while).

> 
> Cheers,
> Jon.
> 
> -----Original Message-----
> From: Peter Zotov [mailto:whitequark@whitequark.org]
> Sent: 08 November 2013 10:19
> To: jon@ffconsultancy.com
> Cc: caml-list@inria.fr
> Subject: RE: [Caml-list] LLVM OCaml bindings
> 
> Jon Harrop писал 08.11.2013 13:36:
>> I just wanted to check: you're not breaking the existing bindings,
>> right?
> 
> Sorry, realized the previous letter was phrased ambiguously.
> I'm asking because I do want to break existing bindings. The changes
> would mainly touch two areas:
> 1) Memory management. I want to get rid of most or all of dispose
> functions and allow to use OCaml's GC.
> 2) Llvm_target interface is very outdated and it could be updated to
> integrate much better with the TargetMachine interface.
> 
> There are also two or three Llvm functions which need minor changes.
> 
> I'm not going to change APIs in any way which needs nontrivial,
> significant fixes to clients, there's simply no need.
> 
> --
>    WBR, Peter Zotov.

-- 
   WBR, Peter Zotov.

Re: [Caml-list] LLVM OCaml bindings

[Jeff Meister]

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

Hi Jon and Peter,

My version of the bindings was constructed to directly wrap the underlying
externals and replace the existing interface, but there's no reason it
couldn't be changed to wrap the existing unsafe bindings instead, and leave
the unsafe interface exposed as well. I'm working on updating my code to
the latest version of LLVM, and I can incorporate that change.

I haven't looked at the Haskell bindings, but I don't think I've been very
tricky with mine. My goal was simply to take the existing bindings over the
unsafe C interface and re-establish the type safety that exists in LLVM's
C++ code by reintroducing the inheritance hierarchy on the OCaml side. I
need a couple unusual patterns for this, but otherwise it's still the
low-level C API, you just don't have everything represented as a top-level
function anymore. For example, "val function_call_conv : llvalue -> int"
becomes "method call_conv : int" inside class Function.c. Translating code
from the existing bindings to my version would be straightforward and
mechanical.

Aside from compatibility with existing code though, I can't imagine why any
OCaml programmer would want to use a type-unsafe version of the LLVM
bindings. The C API gets a pass for flattening LLVM's deep inheritance
hierarchies into opaque pointers like llvalue and lltype, since that's all
C lets you do. But that's just not acceptable to me in OCaml, where I have
the tools to correct the situation. If I have to give up static type safety
to work with LLVM in OCaml, then I might as well not use OCaml on that
project.

If the Haskell bindings expose more capabilities than the OCaml ones, it
would be great to add these additional functions. But I'm curious, how are
they getting additional functions? Can Haskell bind directly to C++ without
going through C? Or have the Haskell folks made major changes to the LLVM C
API? And if so, why wouldn't they push those changes upstream themselves?


On Fri, Nov 8, 2013 at 3:31 AM, Jon Harrop <jon@ffconsultancy.com> wrote:

> > I'm not going to change APIs in any way which needs nontrivial,
> significant fixes to clients, there's simply no need.
>
> Ok, great.
>
> Jeff Meister was talking about writing more type safe bindings. I think
> that would be fine as long as it wraps the existing less-safe bindings so
> people can continue to use them. I tried using LLVM from Haskell and had a
> lot of problems because they'd used every trick in the book to write the
> most type safe possible bindings and it makes it much harder to learn and
> use. I'd personally much rather see more complete bindings...
>
> BTW, what are your thoughts on MSJIT? I just started reading about it and
> it seems very underwhelming. Sounds like they're struggling to refactor
> their C++ code so they're reinventing things but not doing it significantly
> better. So I don't think I'll be rushing to switch to MSJIT unless they
> actually deprecate the old JIT.
>
> Cheers,
> Jon.
>
> -----Original Message-----
> From: Peter Zotov [mailto:whitequark@whitequark.org]
> Sent: 08 November 2013 10:19
> To: jon@ffconsultancy.com
> Cc: caml-list@inria.fr
> Subject: RE: [Caml-list] LLVM OCaml bindings
>
> Jon Harrop писал 08.11.2013 13:36:
> > I just wanted to check: you're not breaking the existing bindings,
> > right?
>
> Sorry, realized the previous letter was phrased ambiguously.
> I'm asking because I do want to break existing bindings. The changes would
> mainly touch two areas:
> 1) Memory management. I want to get rid of most or all of dispose
> functions and allow to use OCaml's GC.
> 2) Llvm_target interface is very outdated and it could be updated to
> integrate much better with the TargetMachine interface.
>
> There are also two or three Llvm functions which need minor changes.
>
> I'm not going to change APIs in any way which needs nontrivial,
> significant fixes to clients, there's simply no need.
>
> --
>    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: 5226 bytes --]

Re: [Caml-list] LLVM OCaml bindings

[Peter Zotov]

Jeff Meister писал 12.11.2013 07:44:
> Aside from compatibility with existing code though, I can't imagine
> why any OCaml programmer would want to use a type-unsafe version of
> the LLVM bindings. The C API gets a pass for flattening LLVM's deep
> inheritance hierarchies into opaque pointers like llvalue and lltype,
> since that's all C lets you do. But that's just not acceptable to me
> in OCaml, where I have the tools to correct the situation. If I have
> to give up static type safety to work with LLVM in OCaml, then I might
> as well not use OCaml on that project.

Speed? :) Actually, OCaml has much more type safety than C or bindings
of LLVM to dynlangs (Ruby, etc). Ruby bindings didn't even check if I
pass lltype where llvalue is expected, and there was no easy way to do
it.

> If the Haskell bindings expose more capabilities than the OCaml ones,
> it would be great to add these additional functions. But I'm curious,
> how are they getting additional functions? Can Haskell bind directly
> to C++ without going through C? Or have the Haskell folks made major
> changes to the LLVM C API? And if so, why wouldn't they push those
> changes upstream themselves?

They wrote their own C wrappers using the C++ API. I'm currently 
pushing
them upstream, slowly. Haskell folks probably didn't do that because 
it's
somewhat of a pain if you're not an LLVM committer.

> 
> On Fri, Nov 8, 2013 at 3:31 AM, Jon Harrop <jon@ffconsultancy.com> 
> wrote:
> 
>>> I'm not going to change APIs in any way which needs nontrivial, 
>>> significant fixes to clients, there's simply no need.
>> 
>> Ok, great.
>> 
>> Jeff Meister was talking about writing more type safe bindings. I 
>> think that would be fine as long as it wraps the existing less-safe 
>> bindings so people can continue to use them. I tried using LLVM from 
>> Haskell and had a lot of problems because they'd used every trick in 
>> the book to write the most type safe possible bindings and it makes it 
>> much harder to learn and use. I'd personally much rather see more 
>> complete bindings...
>> 
>> BTW, what are your thoughts on MSJIT? I just started reading about it 
>> and it seems very underwhelming. Sounds like they're struggling to 
>> refactor their C++ code so they're reinventing things but not doing it 
>> significantly better. So I don't think I'll be rushing to switch to 
>> MSJIT unless they actually deprecate the old JIT.
>> 
>> Cheers,
>> Jon.
>> 
>> -----Original Message-----
>> From: Peter Zotov [mailto:whitequark@whitequark.org]
>> Sent: 08 November 2013 10:19
>> To: jon@ffconsultancy.com
>> Cc: caml-list@inria.fr
>> Subject: RE: [Caml-list] LLVM OCaml bindings
>> 
>> Jon Harrop писал 08.11.2013 13:36:
>>> I just wanted to check: you're not breaking the existing bindings,
>>> right?
>> 
>> Sorry, realized the previous letter was phrased ambiguously.
>> I'm asking because I do want to break existing bindings. The changes 
>> would mainly touch two areas:
>> 1) Memory management. I want to get rid of most or all of dispose 
>> functions and allow to use OCaml's GC.
>> 2) Llvm_target interface is very outdated and it could be updated to 
>> integrate much better with the TargetMachine interface.
>> 
>> There are also two or three Llvm functions which need minor changes.
>> 
>> I'm not going to change APIs in any way which needs nontrivial, 
>> significant fixes to clients, there's simply no need.
>> 
>> --
>>    WBR, Peter Zotov.
>> 
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list [1]
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners [2]
>> Bug reports: http://caml.inria.fr/bin/caml-bugs [3]
> 
> 
> 
> Links:
> ------
> [1] https://sympa.inria.fr/sympa/arc/caml-list
> [2] http://groups.yahoo.com/group/ocaml_beginners
> [3] http://caml.inria.fr/bin/caml-bugs

-- 
   WBR, Peter Zotov.

RE: [Caml-list] LLVM OCaml bindings

[Jon Harrop]

Jeff Meister wrote:
> If I have 
> to give up static type safety to work with LLVM in OCaml, then I might 
> as well not use OCaml on that project.

Peter Zotov wrote:
> Speed? :)

I use OCaml+LLVM for the algebraic data types, pattern matching, functional programming and so on. Type safety of the bindings is way down on the list for me.

Cheers,
Jon.

Re: [Caml-list] LLVM OCaml bindings

[Hongbo Zhang]

On 11/13/13, 2:00 PM, Jon Harrop wrote:
> Jeff Meister wrote:
>> If I have
>> to give up static type safety to work with LLVM in OCaml, then I might
>> as well not use OCaml on that project.
>
> Peter Zotov wrote:
>> Speed? :)
>
> I use OCaml+LLVM for the algebraic data types, pattern matching, functional programming and so on. Type safety of the bindings is way down on the list for me.

agreed, the major benefit for me compared with c++, is compile time 
performance, pattern matching and toplevel -- the type safety of the 
bindings is nice
but not necessary if it brings too much complexity to the API

> Cheers,
> Jon.
>
>
>

Re: [Caml-list] LLVM OCaml bindings

[Jeff Meister]

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

There is basically no extra complexity, just refactoring. The only
difference is that, for example, setting the initializer for a
GlobalVariable.c statically requires a Constant.c, not just any llvalue as
allowed by the existing bindings. I don't see this as additional
complexity, because you have to know the real types anyway to work with the
current bindings. I'm simply making them explicit in the interface. There
is unfortunately the annoyance of frequent upcasts: to past your Constant.c
x to a function that expects a Value.c, you must write (x :> Value.c). But
that limitation of the OCaml language can be removed, and it already has
been in the implicit_subtyping branch. I would love to see those changes
integrated into mainline OCaml, or at least updated to work with the latest
release! :)

You guys are right that I was too sweeping with my statement about type
safety... the other features you mentioned are great reasons to prefer
OCaml, and they're important to me too. What I should have said was, I
don't want to have to sacrifice type safety of the bindings so I can work
in OCaml, especially when I see no fundamental reason why that sacrifice is
necessary. Frankly I was very surprised when I first discovered that the
bindings are so inadequate in this respect, and that no one had done
anything about it. Maybe that's because no one cares, but I doubt it. It
may not be the most important thing, but I see it as free help from OCaml's
type and module systems, and I'll take that help, especially when working
with such a large and complex project like LLVM.


On Thu, Nov 14, 2013 at 8:06 AM, Hongbo Zhang <bobzhang1988@gmail.com>wrote:

> On 11/13/13, 2:00 PM, Jon Harrop wrote:
>
>> Jeff Meister wrote:
>>
>>> If I have
>>> to give up static type safety to work with LLVM in OCaml, then I might
>>> as well not use OCaml on that project.
>>>
>>
>> Peter Zotov wrote:
>>
>>> Speed? :)
>>>
>>
>> I use OCaml+LLVM for the algebraic data types, pattern matching,
>> functional programming and so on. Type safety of the bindings is way down
>> on the list for me.
>>
>
> agreed, the major benefit for me compared with c++, is compile time
> performance, pattern matching and toplevel -- the type safety of the
> bindings is nice
> but not necessary if it brings too much complexity to the API
>
>
>  Cheers,
>> Jon.
>>
>>
>>
>>
>
> --
> 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: 3776 bytes --]