<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 17, 2015 at 8:35 PM James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">jyknight added a comment.<br>
<br>
So, I think that asking for more data collection is not actually useful.<br>
<br></blockquote><div><br></div><div>I agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From the "do people need MORE stable than this proposal provides" side: it's not that I think having an actually-fully-stable interface that WebKit and Rust and everyone else could use would not be useful to them -- it's that LLVM developers are not willing/able to put up with the restrictions that places on the codebase. So asking people "hey would you like a more stable api?" is not worthwhile. Obviously, yes, all other things equal I'd like that. But it's not going to happen -- there's a lot of pushback from LLVM developers about not inconveniencing development of the LLVM C++ code.<br>
<br></blockquote><div><br></div><div>I don't necessarily agree here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You might instead ask: "Hey would you like to have a completely stable LLVM C API, but that has a much much smaller set of functionality exposed?". And I already know the answer to that: "no". Most users //already// have to add their own custom wrappers for APIs that aren't exposed in the llvm-c api (typically, things that really ought to be right there next to one of the existing APIs, but aren't because it's very hard to get any additions approved!). Having //less// is just not going to be useful.<br>
<br></blockquote><div><br></div><div>This is fine.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(I'll just note: the fact that people have to add their own C++ code doesn't mean the C API is useless! It's a huge head-start -- that's quite helpful even if you also need custom C++ wrappers!)<br>
<br>
Literally the ONLY "stable API" user that I think currently exists is ld64 -- and that is only because they have designed and deployed their own private API. llvm-c/lto.h has, to the best of my knowledge, just the one user. Everyone else works fine with "pseudo-stable".<br>
<br></blockquote><div><br></div><div>Some of the APIs have been more stable than you expect over time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And everyone else using LLVM that I know of wants to access a wide swath of functionality, from IR Building, to custom pass setup, to jit compiling/linking. All of that cannot possibly be provided in guaranteed-stable form without inconveniencing LLVM development.<br>
<br></blockquote><div><br></div><div>You are incorrect as I said in my earlier comment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I mean, let's take examples: Rust, WebKit, Mono, or the Radeon R600 Mesa driver? tThere's really no way what they're doing can be provided as "stable".<br>
<br></blockquote><div><br></div><div>It depends.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As far as I can see a useful "stable API" is basically impossible, and should be off the table for that reason alone.<br>
<br></blockquote><div><br></div><div>I think you missed something in my previous emails. It could be because the thread is so long at this point or that I'm apparently terrible at communicating lately.</div><div><br></div><div>a) I'm proposing two APIs. One stable, one not stable. The "bindings API" I've said _could_ be autogenerated, or not. I don't care. It's allowed to grow without bound. The stable API, as I proposed in my last mail is much smaller. It involves things that we already say we're going to support - autoupgrading of bitcode. This is the suggestion I had before for a JIT API. Things that _read_ but do not write bitcode we can support in at least a small way. Personally I'd want this to be an API that is suitably abstract rather than a light covering over the JIT as we have now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
___<br>
<br>
The next question is from the other direction: maybe we should just ditch the llvm-c API entirely, and use an autogenerated C binding generator instead?<br>
<br>
I really think that idea is just a distraction.<br>
<br>
Firstly, auto-generated bindings typically target the end language, not C. (e.g. with swig, boost::python, etc). So you probably wouldn't even want a C API at all, if that's the way you want to do things. You'd probably just expose the C++ api directly to Python, Perl, etc.<br>
<br></blockquote><div><br></div><div>See above. Also nearly every set of bindings I've seen use C as an FFI and not C++. If you have other knowledge I'd love to hear it (honestly, I've just never seen it).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But more importantly, this autogenerated llvm C binding doesn't exist. If someone had created it, it could be reasonably examined and considered as a replacement for the LLVM-C API, weighing any advantages and disadvantages. (My expectation is that it would not be an improvement, and would fail if put to such a comparison.) But right now it's vaporware! As such, talking about it as if it was a real alternative is not useful.<br>
<br></blockquote><div><br></div><div>Again, I'm not talking about this. However, I'll repeat what I said above: I am, and have been for some time, proposing two APIs.</div><div>One: very limited, reasonably stable guarantees (or at least a Really Good Reason(tm) for breaking it). Should probably be tested.</div><div><br></div><div>Two: very expansive, no guarantees. Can be autogenerated for all I care, or not. Don't care if it's tested either.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
___<br>
<br>
What we HAVE now is the LLVM-C API -- and it's actually pretty damn good. What it needs is the ability to continue to evolve alongside changes in the underlying LLVM library, without being held back (and without threats of deletion) due to concerns of exposing "too much" functionality.<br>
<br></blockquote><div><br></div><div>No, it sucks to put not too fine a point on it. I'm unwilling to let anything else in and so have irritated people in one direction (people that want more apis) and it changes on occasion causing incompatibilities (causing problems in the other direction for people wanting things that are more stable).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, bottom line, I think there are only three realistic alternatives:<br>
a) Approximately what I've written in this diff.<br>
b) "Anything goes" (make any changes you like, no stability rules whatsoever).<br>
c) Just delete the LLVM-C API entirely.<br>
<br></blockquote><div><br></div><div>Or a fourth. :)</div><div><br></div><div>-eric</div><div> </div><div> </div></div></div>