[PATCH] D12685: Document the stability policy for LLVM-C APIs.

[James Y Knight via llvm-commits]

jyknight added a comment.

So, I think that asking for more data collection is not actually useful.

>From the "do people need MORE stable than this proposal provides" side: it's not that I think having an actually-fully-stable interface that WebKit and Rust and everyone else could use would not be useful to them -- it's that LLVM developers are not willing/able to put up with the restrictions that places on the codebase. So asking people "hey would you like a more stable api?" is not worthwhile. Obviously, yes, all other things equal I'd like that. But it's not going to happen -- there's a lot of pushback from LLVM developers about not inconveniencing development of the LLVM C++ code.

You might instead ask: "Hey would you like to have a completely stable LLVM C API, but that has a much much smaller set of functionality exposed?". And I already know the answer to that: "no". Most users //already// have to add their own custom wrappers for APIs that aren't exposed in the llvm-c api (typically, things that really ought to be right there next to one of the existing APIs, but aren't because it's very hard to get any additions approved!). Having //less// is just not going to be useful.

(I'll just note: the fact that people have to add their own C++ code doesn't mean the C API is useless! It's a huge head-start -- that's quite helpful even if you also need custom C++ wrappers!)

Literally the ONLY "stable API" user that I think currently exists is ld64 -- and that is only because they have designed and deployed their own private API. llvm-c/lto.h has, to the best of my knowledge, just the one user. Everyone else works fine with "pseudo-stable".

And everyone else using LLVM that I know of wants to access a wide swath of functionality, from IR Building, to custom pass setup, to jit compiling/linking. All of that cannot possibly be provided in guaranteed-stable form without inconveniencing LLVM development.

I mean, let's take examples: Rust, WebKit, Mono, or the Radeon R600 Mesa driver? tThere's really no way what they're doing can be provided as "stable".

As far as I can see a useful "stable API" is basically impossible, and should be off the table for that reason alone.

___

The next question is from the other direction: maybe we should just ditch the llvm-c API entirely, and use an autogenerated C binding generator instead?

I really think that idea is just a distraction.

Firstly, auto-generated bindings typically target the end language, not C. (e.g. with swig, boost::python, etc). So you probably wouldn't even want a C API at all, if that's the way you want to do things. You'd probably just expose the C++ api directly to Python, Perl, etc.

But more importantly, this autogenerated llvm C binding doesn't exist. If someone had created it, it could be reasonably examined and considered as a replacement for the LLVM-C API, weighing any advantages and disadvantages. (My expectation is that it would not be an improvement, and would fail if put to such a comparison.) But right now it's vaporware! As such, talking about it as if it was a real alternative is not useful.

___

What we HAVE now is the LLVM-C API -- and it's actually pretty damn good. What it needs is the ability to continue to evolve alongside changes in the underlying LLVM library, without being held back (and without threats of deletion) due to concerns of exposing "too much" functionality.

That's what this proposal is about.

The minimal effect of a policy here needs to be that LLVM developers are comfortable enough to allow new APIs to be added to the LLVM-C API set, without objecting each time.

So, bottom line, I think there are only three realistic alternatives:
a) Approximately what I've written in this diff.
b) "Anything goes" (make any changes you like, no stability rules whatsoever).
c) Just delete the LLVM-C API entirely.

Obviously, I think (a) is the best choice. And if forced, I'd go with (b) over (c).


http://reviews.llvm.org/D12685