[LLVMdev] [RFC] Developer Policy for LLVM C API

[David Chisnall]

On 20 Jul 2015, at 05:54, Chris Lattner <clattner at apple.com> wrote:
> 
> The entire original reason for the C API is to provide a stable interface for people who didn’t want to chase the C++ API (or didn’t want to chase *as much* of it).  In this sense, I consider the LLVM C API to be unlike the other “bindings” for generating IR: its purpose is to remain stable, not to be a language binding for people who prefer to write things in C.

I’m not convinced that this has worked.  We’ve done some cleanup in the FreeBSD ports tree recently, but we still have LLVM 3.3-3.7 to support all of the external projects that are using it.  3.3 looks as if it is down to only one consumer (the DRI drivers for X11, which is probably the most high-profile user of LLVM for most of our users).  Most external projects are using the C++ APIs because they invariably find at least one thing that isn’t covered by the C APIs that they need to do and just eat the cost of periodically moving to newer versions.

The instability of the C++ APIs means that we can move fast, which is very nice, but it also means that external projects typically jump from release to release (often skipping one or more) and so we don’t get nearly as good testing as we would if we had more external users of a stable API, who could just grab head, recompile, and run their own test suites every week or so.

Given libClang, the goal of a C API as bindings ought to be much simpler - we should just be able to annotate some classes that we want to export and machine-generate a C API with the same stability guarantees as the C++ API.  If we want a stable API that’s actually useful, then this needs much more careful thought about what its requirements are.  Splitting it into separate sets of interfaces might make sense.  About the only thing that you can really do with the existing C APIs is write a front end, so making sure that we have a stable API for generating LLVM IR, a stable API for instantiating a JIT / generating object code, and (once LLD is a bit more mature) a stable API for generating linked binaries, would be of significant value.  A stable API for writing out-of-tree passes would be very nice, but is almost certainly impossible as it relies on IR stability.  A stable API for out-of-tree backends is likely to be completely impossible for a long time.

David