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
> 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. -Filip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140805/d48a38b6/attachment.html>
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