[llvm-dev] The future of LLVM's C APIs: Notes and BoF.

Markiyan Kushnir via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 22 05:44:52 PDT 2015


2015-10-17 21:20 GMT+03:00 Justin Bogner via llvm-dev <llvm-dev at lists.llvm.org>:
> (Moving this to llvm-dev)
>
> On Friday, October 16, 2015, Justin Bogner <mail at justinbogner.com> wrote:
>>
>> Some users of llvm-c want stable API interfaces into various parts of
>> the LLVM infrasture, others want further ABI guarantees about this
>> usage, and still others simply want a way to bind to LLVM through their
>> language frontend’s existing FFI support for C.
>>
>> If we want to improve the situation for any of these users, we need to
>> properly understand how these APIs are being used (or abused)
>> today. Juergen and I will be hosting a BoF at the dev meeting where we
>> can discuss what the requirements of a sustainable C API are, and how we
>> can organize things in LLVM to support this.
>>
>> There's been a fair amount of discussion about this lately, and it's
>> pretty clear that the "hopefully stable bindings to whatever APIs
>> somebody needed" approach isn't really good enough for anybody. There
>> are a couple of points that I think are fairly non-controversial, but
>> will more or less drive the discussion at the BoF:
>>
>> 1. It isn't practical to keep a bindings API stable, unless the
>>    underlying API is also stable.
>>
>> 2. Handrolling bindings as they're needed tends to leave conspicuous
>>    gaps where some API is inaccessible for no good reason.
>>
>> So based on (1), we'll really want to create some purpose built APIs
>> that we can keep stable for various tasks. What's needed here? People
>> want to do things like building a pass manager, setting up a canned JIT
>> config, and to some degree even emit IR. We'll discuss what's practical
>> and what people want, and hopefully strike a good balance.
>>
>> Similarly, (2) implies that if we really need a *full* bindings API
>> we'll want to automate it. But what is a full bindings API? Who uses it,
>> and what do they want from it? If it's automated, should installing LLVM
>> install this API, or should we simply provide an easy way to generate
>> it?
>>
>> In the end, I hope to have a good idea of what people are actually using
>> these APIs for, and both to support stable API users less haphazardly
>> and to make unstable API more thorough and/or easier to create.
>
>

I'm using LLVM in my own DSL implemented in pure C, in-memory
compilation/execution of DSL within a long-running application.  I use
LLVM C API heavily to build LLVM modules, generate machine code out of
them and execute it.  Since I link LLVM components into my library
statically, I'm OK to have unstable yet rich C API (possibly
automatically generated, yet clearly documented in header files), and
adjust/re-compile my own things with the new LLVM release.  I realize
that I would not necessarily need the absolutely full set of LLVM API,
so I would like having some options in C API automatic generation.  My
use cases:

    - Using the full IR building capabilities;

    - running passes over modules and individual functions via pass
manager, configuring pass manager via pass manager builder (possibly
more advanced pass manager and/or pm builder uses);

    - I'm using LLVMCreateJITCompilerForModule() in 3.4, 3.5. (Tried
MCJIT in 3.6 but could not reach an equivalent of the former.);

    - getting pointers to compiled objects (LLVMGetPointerToGlobal)
and accessing/executing them at run time;

    - generating textual IR/assembly for debugging purposes;

    - during my DSL recompile, it's important to cleanly dispose the
LLVM context and other LLVM resources using C API in a long running
application (months);

    - something off this topic: nice to have an option to not
link/depend on libraries related to interactive console and/or
graphical features.




> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


More information about the llvm-dev mailing list