[LLVMdev] LLVM as a shared library

[Eric Christopher]

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.

-eric