<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-08-17 8:34 GMT-07:00 Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span>:<br><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"><span class="">On Sun, Aug 16, 2015 at 10:34 PM, deadal nix via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-08-16 21:51 GMT-07:00 Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span>:</span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>The promise of stability. We don't promise that the C++ API will stay stable.</div></div></div>
</blockquote></span></div><br><br></div></div></div><span class=""><div class="gmail_extra">Why was that promise be made in the first place ? Has it been made in the first place ?<br></div></span></div></blockquote><div><br></div><div>It sounds like you're in favor of dropping C API stability then, if it's holding us back? That feedback is actually really helpful. :)</div><div><br></div><div>There are really three goals here: flexibility to change LLVM IR, completeness of the C API, and stability of the C API. Pick two.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Yes but these aren't black and white IMO. These are need in tension, sure, but all API have these kind of problem not specifically the C API.<br><br></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>The goals are mutually incompatible and we have to trade off one for the other. Most of the LLVM core developers value goal #1, the ability to change the IR. Look at the pointee type changes that David Blaikie is working on, and the new EH representation. If we promise both stability and completeness, these things are impossible.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Yes I was actually thinking about that. This is the kind of change that justify a change in the C API IMO. We should try our best to keep the C API stable, but if somethign fundamental changes in LLVM, and that there is no nice way to map it to the old API, then <br><br></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>One way forward is to guarantee stability, but limit completeness. This would mean limiting the C API to constructs that will always and forever be easily represented in LLVM.</div><div><br></div></div></div></div></blockquote><div><br></div><div>That would be a problem for me. It seems like other in this thread mentioned the incompleteness of the C API as a problem for them and mentioned the use of various hacks to work around it. On my side I tried to propose diff to increase completeness of the C API in the past, but the review process was frankly too painful and I mostly give up. I'd be up for being a maintainer of the C API if that is needed.<br><br></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>The other choice is to forget stability and wrap the C++ API completely, potentially with something auto-generated. We could make a more limited stability promise along the lines of "these APIs will be updated to reflect changes to the IR, and are otherwise stable." I think everyone would be fine with that.</div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">I do not think this is a good idea. The C API is used a lot to use LLVM from other languages than C++ . When used directly from C, you get function signature, but when used from other languages, changing method randomly cause undefined behavior. For instance, the landing pad instruction was changed recently and the C API to create a landing pad was updated. As a result, 2 thing happened :<br></div><div class="gmail_extra"> - It was not possible to set the personality function from C, which is a problem for many frontends.<br></div><div class="gmail_extra"> - In other languages, as mangling remained the same, the thing compiles and fail randomly at runtime.<br><br></div><div class="gmail_extra">This need to be avoided as much as possible. I'd propose the following policy :<br></div><div class="gmail_extra">1/ Do change the IR as per need of LLVM development. The C API must not prevent LLVM to move forward.<br></div><div class="gmail_extra">2/ If the change can be mapped nicely without changing the C API, then do that.<br></div><div class="gmail_extra">3/ If there is no way to map it nicely, then update the C API.<br><br></div><div class="gmail_extra">For instance, the pointer update work would probably be a valid reason to go with 3/ .<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Right now, as far as I'm concerned, the main limitation of the C API are the capability to set attributes and the capability to use atomic loads/stores.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">In any ways, I do think the patch adding tests for existing API should be merged. The need for test for the C API was mentioned various times in this thread and I do think that whatever the road taken, having test is a good thing.<br></div></div>