> (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. -eric
> 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.Or at least document what our backwards compatibility promises are and how we transition away from old APIs. Two examples where we do break C APIs: * An hypothetical off by one source range bug in clang. It will break a user of libclang that might have been compensating for the bug. In cases like this we seem to just assume there is a low risk and just fix the bug. * Dropping features like the old JIT. It will break users of the C API that depend on the old JIT. In cases like this we provide an upgrade path (MCJIT) and a deprecation period. Cheers, Rafael
> 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? -Filip
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:13 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> 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. > > Or at least document what our backwards compatibility promises are and > how we transition away from old APIs.Right. I believe this is the right approach.> > Two examples where we do break C APIs: > > * An hypothetical off by one source range bug in clang. It will break > a user of libclang that might have been compensating for the bug. In > cases like this we seem to just assume there is a low risk and just > fix the bug.Yup. Speaking for WebKit: we would be happy to get rid of workarounds even if it meant a brief period of breakage. We would handle that breakage on our end by ensuring that we don’t build the new (sans workaround) version of WebKit against the old (pre bugfix) version of LLVM or vice-versa. We’re OK with short-term pain for long-term gain.> > * Dropping features like the old JIT. It will break users of the C API > that depend on the old JIT. In cases like this we provide an upgrade > path (MCJIT) and a deprecation period.Yup. I wonder how many people still use the old JIT via the C API. I know of old JIT users but I thought that many (most? all?) were using the C++ API. -Filip