[LLVMdev] LLVM as a shared library

[Eric Christopher]

On Tue, Aug 5, 2014 at 2:57 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>
> On Aug 5, 2014, at 2:51 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> On Tue, Aug 5, 2014 at 2:49 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>
>
> On Aug 5, 2014, at 1:46 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> (7) Make the C API truly great.
>
> I think it’s harmful to LLVM in the long run if external embedders use the
> C++ API.  I think that one way of ensuring that they don’t have an excuse to
> do it is to flesh out some things:
>
> - Add more tests of the C API to ensure that people don’t break it
> accidentally and to give more gravitas to the C API backwards compatibility
> claims.
> - Increase C API coverage.
>       - For example, WebKit currently sidesteps the C API to pass some
> commandline options to LLVM.  We don’t want that.
>       - Add more support for reasoning about targets and triples.  WebKit
> still has to hardcode triples in some places even though it only ever does
> in-process JITing where host==target. That’s weird.
>       - Expose debugging and runtime stuff and make sure that there’s a
> coherent integration story with the MCJIT C API.
>               - Currently it’s difficult to round-trip debug info: creating
> it in C is awkward and parsing DWARF sections that MCJIT generates involves
> lots of weirdness.  WebKit has its own DWARF parser for this, which
> shouldn’t be necessary.
>               - WebKit is about to have its own copies of both a
> compactunwind and EH frame parser.  The contributor who “wrote” the EH frame
> parser actually just took it from LLVM.  The licenses are compatible, but
> nonetheless, copy-paste from LLVM into WebKit should be discouraged.
> - Engage with non-WebKit embedders that currently use the C++ API to figure
> out what it would take to get them to switch to the C API.
>
> I think that a lot of time when C API discussions arise, lots of embedders
> give excuses for using the C++ API.  WebKit used the C API for generating IR
> and even doing some IR manipulation, and for driving the MCJIT.  It’s been a
> positive experience and we enjoy the binary compatibility that it gives us.
> I think it would be great to see if other embedders can do the same.
>
>
> Honestly I think if you want to make the C API great we should burn it
> to the ground and come up with another one - and one that can be
> versioned as well so we don't have the problems of being limited in
> what we can do to llvm by needing compatibility with the C API.
>
>
> Can you come up with specific reasons why building a new API would be better
> for the community than maintaining the one we’ve got?
>
>
> Rafael came up with a few in his, but also having an API that lightly
> wraps the C++ api is hard if we want to change a major C++ interface
> or completely remove a class, etc. There's no existing way in the API
> to either version or remove an interface given our current promises.
>
>
> Can you give a specific example of an intended C++ API change that wasn’t
> possible because of a C API?
>
> Just because you have an API doesn’t mean that things can’t be deprecated,
> or that the API layer can’t be hacked to give the illusion of old behavior.
> Can you give an example of a C API deprecation proposal that was intended to
> make some C++ change possible, that was rejected on the grounds that it
> would break the C API?
>
> I can only recall cases where the C API was broken by accident because of
> lack of testing, and in all of those cases, the issue was either resolved,
> or there is a plan to resolve it and a workaround was made available.
>

Sure, these are going to be a bit vague because I'm a bit busy at the
moment, but I recall a couple of times during the year that we've had
API up for review (or even committed temporarily) that exposed
internal constants via enums, and I think Rafael had some issues with
visibility changes for the same reasons.

In a more recent case here's a thread:

[LLVMdev] Inconsistent third field in global_ctors (was Re: [llvm]
r214321 - UseListOrder: Visit global values)

and

[PATCH] Add return value attribute to C interface

also I think the conversation we were having in here:

[PATCH] Expose MCInst in C Disassembler API

is somewhat relevant :)

Just a couple of quick things I could find with a search. I could
probably dig up more given some more time.

-eric