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

[Sean Silva via cfe-dev]

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)

-- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151019/552c7a38/attachment.html>