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

[Eric Christopher via cfe-dev]

On Mon, Oct 19, 2015 at 10:46 PM Sean Silva via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Fri, Oct 16, 2015 at 9:14 PM, Justin Bogner via cfe-dev <
> cfe-dev at lists.llvm.org> 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.
>>
>
> Do people actually care about it being an API for "LLVM"? Would they be
> happy with a library that is merely "LLVM-powered"? It seems like an
> "LLVM-powered" library would have a similar maintenance burden as a
> (non-clang) language frontend; the downside being that it would not allow
> blindly copying what is on the C++ side and hence and would require a
> significant up-front API design effort.
>
> (not necessarily wanting to discuss that here in this thread, but just
> throwing a wild stab into the pot for discussion)
>
>
I brought up some similar things to this in the very very long email
discussions before.

-eric


> -- Sean Silva
>
>
>>
>> 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.
>>
> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151020/31b8ab57/attachment.html>