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

Thu Oct 22 07:11:52 PDT 2015

On Oct 17, 2015, at 12:14 AM, Justin Bogner via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 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. 

I actually almost entirely disagree with the above. :)

I believe that "somewhat stable bindings to whatever APIs people needed" *IS* good enough for users of these bindings, and I still would like to see that as the official policy (as per the code review I sent out before, proposing that, http://reviews.llvm.org/D12685 <http://reviews.llvm.org/D12685>).

Yes, the current situation sucks, but as I see it, the major problem is that additional bindings that people want, and attempt to add, get VETOED, because of the fear of imposing an impossible future compatibility guarantee.

The solution is to stop imposing an impossible compatibility guarantee. I strongly believe that's literally the ONLY change that needs to be made to fix the current situation.

Again, while we're causing this self-inflicted wound: what do users actually gain from it? Basically nothing. They still need to use the C++ API anyways, so the stablity provided is illusory. It's essentially impossible to depend on the theoretical 100% ABI/API guarantee today.

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

Yes, I agree with this.

> 2. Handrolling bindings as they're needed tends to leave conspicuous
>   gaps where some API is inaccessible for no good reason.

I disagree on the main cause of the gaps. Once we fix the compatibility policy, APIs can start being added again by interested parties to keep pace with additions to the LLVM C++ API (as happened in the earlier days of the project, before we hit this logjam!).

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

I think this is basically a diversion from the issue at hand.

Firstly, I don't believe there is a real need for inventing a brand new, super-restricted (necessarily! because if it was fully general it couldn't be stable!) set of stable APIs. Even if there is a real need -- which has NOT been demonstrated -- someone will have to do that work. I've seen nobody volunteer to do that. I find this discussion of a yet-to-be-invented-actually-supportably-stable API a diversion from what to actually do, RIGHT NOW, to unblock proper maintenance for our EXISTING API. 

Maybe someone will want to come up with a new set of APIs and a way to build a llvm shared library with a stable so-version, someday. Maybe they won't. If they do in the future -- that's fine. Let's have the discussion then. But in the meantime, I'd really like the existing APIs to start having a sane maintenance policy.

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

I disagree with this as well. I think the quality of the APIs that come out of auto-generated bindings are typically below par, and that the LLVM-C APIs are actually overall well designed, and, before a few years ago, covered much of what people wanted to do. I do not think they should be discarded or deprecated. Furthermore, these auto-generated bindings are, again, non-existent -- nobody has yet actually proposed what these would look like or worked on creating such a thing.

Again, the problem I see is that people are being effectively blocked from adding APIs to the LLVM-C bindings right now -- people ARE volunteering to do that work but can not!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151022/8e12a51e/attachment-0001.html>