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

deadal nix via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 22 10:10:59 PDT 2015


A C API (the code is not written in C or C++, and C is kind of the
Esperanto of programming). Preferably a ABI-stable C API, as no
typechecking is going to be done at language boundary. That being said, I
would put the ABI condition as a *should* rather than as a *must*.

2015-10-22 2:42 GMT-07:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:

> On 22 Oct 2015, at 02:52, deadal nix via llvm-dev <llvm-dev at lists.llvm.org>
> wrote:
> >
> > Back on point, the importants things for me to do through the C API are :
> >  - Write IR, including debug infos and other metadata (it is mostly
> good, some IR specificities are not covered, like ordered loads/stores, but
> these are edges cases that ca be added. I can prepare a patch if people
> want these).
> >  - Read IR, so I can do transformations.
> >  - Codegen to object files
> >  - JIT (using MCJIT is fine, Orca would be better but making a good C
> api for it may prove challenging).
>
> Just to clarify, are your requirements for:
>
> - A C API?
> - A stable C API?
> - An ABI-stable C API?
> - An API?
> - A stable API?
> - An ABI-stable API?
>
> For most of these things, I’d be happy with a stable C++ API (ABI-stable
> within major releases, recompile - but nothing else - needed between),
> which could potentially be wrapped in a machine-generated C API for
> bindings in other languages.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151022/e78a239b/attachment.html>


More information about the llvm-dev mailing list