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

Hal Finkel hfinkel at anl.gov
Mon Jul 20 06:05:24 PDT 2015


----- Original Message -----
> From: "David Chisnall" <David.Chisnall at cl.cam.ac.uk>
> To: "Chris Lattner" <clattner at apple.com>
> Cc: "Lang Hames" <lhames at apple.com>, "LLVM Dev" <llvmdev at cs.uiuc.edu>
> Sent: Monday, July 20, 2015 3:02:27 AM
> Subject: Re: [LLVMdev] [RFC] Developer Policy for LLVM C API
> 
> 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. 

I agree. To provide an explicit example, look at all the LLVM version dependencies in:
  https://github.com/o11c/llpy/blob/master/llpy/c/core.py
  https://github.com/o11c/llpy/blob/master/llpy/c/object.py
  (etc.)

> 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.

This has been my experience as well.

 -Hal

> 
> 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
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory




More information about the llvm-dev mailing list