From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id B4B637EE25 for ; Tue, 5 Nov 2013 12:32:59 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of whitequark@whitequark.org) identity=pra; client-ip=176.58.103.125; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of whitequark@whitequark.org designates 176.58.103.125 as permitted sender) identity=mailfrom; client-ip=176.58.103.125; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.whitequark.org) identity=helo; client-ip=176.58.103.125; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="postmaster@mail.whitequark.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUMAP3WeFKwOmd9/2dsb2JhbABagz+DBFeGR7UgS4E9dIIlAQEFIw8BBVEEBQIYAgImAgIsKwYbE4dqCZAGm16SOQSBKYgIg1CCXxaCVYFEA4k6oFmDKzc X-IPAS-Result: AuUMAP3WeFKwOmd9/2dsb2JhbABagz+DBFeGR7UgS4E9dIIlAQEFIw8BBVEEBQIYAgImAgIsKwYbE4dqCZAGm16SOQSBKYgIg1CCXxaCVYFEA4k6oFmDKzc X-IronPort-AV: E=Sophos;i="4.93,639,1378850400"; d="scan'208";a="33814995" Received: from fehu.whitequark.org (HELO mail.whitequark.org) ([176.58.103.125]) by mail3-smtp-sop.national.inria.fr with ESMTP; 05 Nov 2013 12:32:58 +0100 Received: by mail.whitequark.org (Postfix, from userid 33) id 9D0664D715; Tue, 5 Nov 2013 15:32:57 +0400 (MSK) To: X-PHP-Originating-Script: 1000:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 05 Nov 2013 15:32:57 +0400 From: Peter Zotov In-Reply-To: <5278D1D1.4060009@gmail.com> References: <5278D1D1.4060009@gmail.com> Message-ID: <523e06f6b965a40b16bc8fe69a88e339@whitequark.org> X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/0.8.6 Subject: Re: [Caml-list] LLVM OCaml bindings 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.