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

[Hal Finkel]

----- Original Message -----
> From: "Hayden Livingston" <halivingston at gmail.com>
> To: "Eric Christopher" <echristo at gmail.com>
> Cc: "Chris Lattner" <clattner at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Lang
> Hames" <lhames at apple.com>
> Sent: Sunday, July 19, 2015 10:37:11 PM
> Subject: Re: [LLVMdev] [RFC] Developer Policy for LLVM C API
> 
> While I understand the people committing to the primarily C++
> codebase
> of LLVM find it as additional burden, far more number of people enjoy
> the benefits of an official LLVM C API support than are vocal here.
> 
> While Clang maybe the first-class LLVM citizen for the foreseeable
> future, I can tell you LLVM is used in many more situations (I'm
> talking about Rust, Go, Julia, DLang, etc.) than this alias realized.
> I alone am using it interesting projects I hope to release sometime
> this year and all of these projects rely on the comfort of the
> "official" C API.

Do you require long-term cross-release ABI and/or API stability from the C API that you're using? Do these other projects? FWIW, many of us (most I'd guess) are well aware of Rust, Go, Julia, etc. and are excited to see them.

> 
> I sympathize with the community that is not using them but having to
> still maintain and fix bugs. To those of you (on this thread and
> others) who are wanting to remove the C API from the project, please
> tell the community what can be done to improve the situation. Do we
> need bots? People writing tests?

Regardless, we certainly need tests.

> 
> I would like to put my support behind discouraging the idea of
> pushing
> the bindings to a side project.

Clang is a side project ;)

 -Hal

> 
> On Sun, Jul 19, 2015 at 7:24 PM, Eric Christopher
> <echristo at gmail.com> wrote:
> > Hi Chris,
> >
> > On Sun, Jul 19, 2015 at 9:16 AM Chris Lattner <clattner at apple.com>
> > wrote:
> >>
> >> On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> >> >> I am strongly in favor of moving the bindings, C or otherwise,
> >> >> to
> >> >> another project.
> >> >
> >> > I agree. From my viewpoint we have two primary problems with the
> >> > C API:
> >> >
> >> > 1. Many of the LLVM contributors don't use it, and thus, don't
> >> > have a
> >> > great understanding of how it can be most-usefully
> >> > updated/improved, and
> >> > what functionality needs to be exposed. We have most, but not
> >> > all,
> >> > transformations; many, but not all, IR features, etc.
> >> >
> >> > 2. We don't have a good set of tests for it, nor do we have a
> >> > good set
> >> > of tutorials/documentation for it. Our tutorials, specifically,
> >> > are in C++,
> >> > not in C. We could break the C API and we'd likely remain
> >> > unaware for quite
> >> > awhile.
> >> >
> >> > Putting it in a separate project will force those who have a
> >> > stake in
> >> > its existence to take the responsibility of moving it forward.
> >> > Separate
> >> > project, or not, however, we should have a better developer
> >> > policy regarding
> >> > the C API (and the other bindings) that fall under the LLVM
> >> > umbrella.
> >> > Specifically, we should outline what features need to be
> >> > exposed, and we
> >> > should actively maintain (and test for) full coverage of those
> >> > features.
> >>
> >> I don’t understand the motivation for this.  Is there tension
> >> between
> >> clients of the C API that would warrant having different
> >> approaches/implementations?  Moving it out to a subproject to get
> >> better
> >> testing seems a bit silly.
> >>
> >> Personally, unless there is a strong and compelling reason to do
> >> so, I’d
> >> prefer to keep a single set of C bindings to encourage
> >> standardization and
> >> avoid fragmenting the community.
> >>
> >
> >  So, I made this proposal for what I think is a pretty good reason.
> >  There's
> > an "unofficial" as Juergen said, policy that the C API is the
> > stable API.
> > There's nothing wrong with a stable C API, but that's what I'm
> > proposing
> > should move out of tree to where those that are most concerned with
> > it can
> > develop it and ensure that it remains stable for whatever
> > guarantees they
> > want.
> >
> > Some background here:
> >
> > Right now we definitely have this dichotomy between a "bindings" C
> > API and a
> > "stable" C API. The unofficial policy as I mentioned above is that
> > there's
> > one C API and that's the stable API. Over the last 3-5 years or so
> > the
> > "stable" C API has started growing in ways that encompass just
> > about every
> > class and API in llvm. We've occasionally denied bindings level API
> > support
> > because we knew the code in that area was going to change - but
> > just imagine
> > we'd let a few of them in, we wouldn't have been able to do the
> > IR/Metadata
> > split at all. As it is we technically broke the C API, just not in
> > a way
> > that any external user cared about.
> >
> > Back to the proposal:
> >
> > What I'm proposing is that we make the C API that exists in tree a
> > bindings
> > API that has the same stability guarantees as the C++ API. Honestly
> > it'll
> > probably much more stable, but at least then we won't have to worry
> > or
> > revert work because the C API was "too close to the machine" or
> > rather the
> > C++ code.  This means that someone that wants a stable C API can go
> > off and
> > develop one (tests and all) and we can possibly look at bringing it
> > back
> > into tree at some point in the future. For example, if someone
> > comes up with
> > a good "libjit" api then we can look at how the API design works
> > and make
> > sure it's general enough that it's not going to cause undue
> > solidification
> > of the existing APIs.
> >
> > Caveat: I'm not talking about the existing libclang or liblto
> > libraries.
> > Those seem to work and have a small enough API surface that they
> > seem
> > reasonable to support and we can move to a new API if they seem to
> > be
> > hindering development in the future.
> >
> > This help explain where I'm coming from here?
> >
> > Thanks!
> >
> > -eric
> >
> > _______________________________________________
> > 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