<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 19, 2015 at 10:46 PM Sean Silva via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 16, 2015 at 9:14 PM, Justin Bogner via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some users of llvm-c want stable API interfaces into various parts of<br>
the LLVM infrasture, others want further ABI guarantees about this<br>
usage, and still others simply want a way to bind to LLVM through their<br>
language frontend’s existing FFI support for C.<br>
<br>
If we want to improve the situation for any of these users, we need to<br>
properly understand how these APIs are being used (or abused)<br>
today. Juergen and I will be hosting a BoF at the dev meeting where we<br>
can discuss what the requirements of a sustainable C API are, and how we<br>
can organize things in LLVM to support this.<br>
<br>
There's been a fair amount of discussion about this lately, and it's<br>
pretty clear that the "hopefully stable bindings to whatever APIs<br>
somebody needed" approach isn't really good enough for anybody. There<br>
are a couple of points that I think are fairly non-controversial, but<br>
will more or less drive the discussion at the BoF:<br>
<br>
1. It isn't practical to keep a bindings API stable, unless the<br>
underlying API is also stable.<br>
<br>
2. Handrolling bindings as they're needed tends to leave conspicuous<br>
gaps where some API is inaccessible for no good reason.<br>
<br>
So based on (1), we'll really want to create some purpose built APIs<br>
that we can keep stable for various tasks. What's needed here? People<br>
want to do things like building a pass manager, setting up a canned JIT<br>
config, and to some degree even emit IR. We'll discuss what's practical<br>
and what people want, and hopefully strike a good balance.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Do people actually care about it being an API for "LLVM"? Would they be happy with a library that is merely "LLVM-powered"? It seems like an "LLVM-powered" library would have a similar maintenance burden as a (non-clang) language frontend; the downside being that it would not allow blindly copying what is on the C++ side and hence and would require a significant up-front API design effort.</div><div><br></div><div>(not necessarily wanting to discuss that here in this thread, but just throwing a wild stab into the pot for discussion)</div><div><br></div></div></div></div></blockquote><div><br></div><div>I brought up some similar things to this in the very very long email discussions before.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Similarly, (2) implies that if we really need a *full* bindings API<br>
we'll want to automate it. But what is a full bindings API? Who uses it,<br>
and what do they want from it? If it's automated, should installing LLVM<br>
install this API, or should we simply provide an easy way to generate<br>
it?<br>
<br>
In the end, I hope to have a good idea of what people are actually using<br>
these APIs for, and both to support stable API users less haphazardly<br>
and to make unstable API more thorough and/or easier to create.<br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>