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

[Eric Christopher via llvm-commits]

On Thu, Sep 17, 2015 at 8:35 PM James Y Knight <jyknight at google.com> wrote:

> jyknight added a comment.
>
> So, I think that asking for more data collection is not actually useful.
>
>
I agree.


> 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.
>
>
I don't necessarily agree here.


> 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.
>
>
This is fine.


> (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".
>
>
Some of the APIs have been more stable than you expect over time.


> 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.
>
>
You are incorrect as I said in my earlier comment.


> 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".
>
>
It depends.


> As far as I can see a useful "stable API" is basically impossible, and
> should be off the table for that reason alone.
>
>
I think you missed something in my previous emails. It could be because the
thread is so long at this point or that I'm apparently terrible at
communicating lately.

a) I'm proposing two APIs. One stable, one not stable. The "bindings API"
I've said _could_ be autogenerated, or not. I don't care. It's allowed to
grow without bound. The stable API, as I proposed in my last mail is much
smaller. It involves things that we already say we're going to support -
autoupgrading of bitcode. This is the suggestion I had before for a JIT
API. Things that _read_ but do not write bitcode we can support in at least
a small way. Personally I'd want this to be an API that is suitably
abstract rather than a light covering over the JIT as we have now.


> ___
>
> 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.
>
>
See above. Also nearly every set of bindings I've seen use C as an FFI and
not C++. If you have other knowledge I'd love to hear it (honestly, I've
just never seen it).


> 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.
>
>
Again, I'm not talking about this. However, I'll repeat what I said above:
I am, and have been for some time, proposing two APIs.
One: very limited, reasonably stable guarantees (or at least a Really Good
Reason(tm) for breaking it). Should probably be tested.

Two: very expansive, no guarantees. Can be autogenerated for all I care, or
not. Don't care if it's tested either.


> ___
>
> 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.
>
>
No, it sucks to put not too fine a point on it. I'm unwilling to let
anything else in and so have irritated people in one direction (people that
want more apis) and it changes on occasion causing incompatibilities
(causing problems in the other direction for people wanting things that are
more stable).


> 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.
>
>
Or a fourth. :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150918/6ac25c1f/attachment.html>