[cfe-dev] The future of LLVM's C APIs: Notes and BoF.

Justin Bogner via cfe-dev cfe-dev at lists.llvm.org
Fri Oct 16 21:14:25 PDT 2015


Some users of llvm-c want stable API interfaces into various parts of
the LLVM infrasture, others want further ABI guarantees about this
usage, and still others simply want a way to bind to LLVM through their
language frontend’s existing FFI support for C.

If we want to improve the situation for any of these users, we need to
properly understand how these APIs are being used (or abused)
today. Juergen and I will be hosting a BoF at the dev meeting where we
can discuss what the requirements of a sustainable C API are, and how we
can organize things in LLVM to support this.

There's been a fair amount of discussion about this lately, and it's
pretty clear that the "hopefully stable bindings to whatever APIs
somebody needed" approach isn't really good enough for anybody. There
are a couple of points that I think are fairly non-controversial, but
will more or less drive the discussion at the BoF:

1. It isn't practical to keep a bindings API stable, unless the
   underlying API is also stable.

2. Handrolling bindings as they're needed tends to leave conspicuous
   gaps where some API is inaccessible for no good reason.

So based on (1), we'll really want to create some purpose built APIs
that we can keep stable for various tasks. What's needed here? People
want to do things like building a pass manager, setting up a canned JIT
config, and to some degree even emit IR. We'll discuss what's practical
and what people want, and hopefully strike a good balance.

Similarly, (2) implies that if we really need a *full* bindings API
we'll want to automate it. But what is a full bindings API? Who uses it,
and what do they want from it? If it's automated, should installing LLVM
install this API, or should we simply provide an easy way to generate
it?

In the end, I hope to have a good idea of what people are actually using
these APIs for, and both to support stable API users less haphazardly
and to make unstable API more thorough and/or easier to create.


More information about the cfe-dev mailing list