<div dir="ltr"><div><div><div><div><div>Let's not get this die. The C API is too valuable to let this die.<br><br></div>I propose the following plan:<br></div> - Add tests for the current API. This will allow to make sure that everything works and would ensure that changes are made intentionally, nto accidentally.<br></div> - For area that do not exist in the C API right now, and for which support seems needed, we establish a plan to support it according to current functionality and planned evolution.<br></div> - It is understood that the C API require more stability than the C++ one as it is often used accross language boundary where type checking cannot be done. On the other hand, no promise of stability is made so LLVM can still evolve at "ludicrous speed". If a change to LLVM cannot be mapped to the current API, the API is updated.<br><br></div>Deal ?<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-08-17 16:50 GMT-07:00 deadal nix <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-08-17 13:47 GMT-07:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.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"><br><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div><div>I'd propose that the only 100% strict rule should be that if the ABI/API changes, it is done in a way that *loudly* breaks old programs -- e.g. they fail to compile, link, or run (depending on how the other-lang wrappers are accessing the API functions) -- not that you get some random weird misbehavior because a function's argument types or return type has been changed.</div><div><br></div><div>Ideally, if you're going to remove an API, you'd deprecate it first, if you can see the problem coming. Otherwise, oh well -- it's not reasonable to hold up LLVM development to adhere to deprecation policy on the C API.<br></div><div><br></div></div></div><div>That is:</div><div>1) Adding new functions for new LLVM functionality: great.</div><div>2) Removing old functions: if it's required -- after careful deliberation.</div><div>3) Modifying the signature of existing functions: no way.</div><div><br></div><div>A couple of concrete examples:</div><div><br></div><div>- Let's say you run out of space in an existing enum type (ahem, LLVMAttribute...).</div><div><br></div><div>You should introduce new function names, taking a better type (perhaps some sort of set type, instead of a fixed-width integer...), mark the old ones deprecated so that users will update to the new functions. But, keep the old ones around so that old code can keep working. There's no real need to remove the old deprecated functions -- they'll keep working as well as they ever did with the smaller-valued attributes.</div></div></blockquote></span><div><br>But does it? What if the code is checking if two functions have the same attributes (perhaps this is an invalid notion in the absence of information about specific attributes) - if you compare the smaller-ranged attributes, you might incorrectly conclude that these two functions have the same attributes. Similarly for "no attributes specified" - you look at the enum, see that none are set & conclude that it's a plain, uninteresting function - so you create another plain, no-attributes function you think you can make equivalent.</div><span><div> </div></span></div></blockquote><div><br></div></span><div>The attribute situation is fairly symptomatic of the state of the C API. You have 2 person in this thread that tried to improve that part of the API but eventually gave up. You have more person in that thread saying they'd need it and have to do various workaround to get things done without it.<br></div><span class=""><div><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"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>- Let's say you remove types from pointers.</div><div><br>This is a change that can be seen coming up. So, one should fairly early on add an LLVMBuildGEP2 function that takes the extra type argument. Leave the old function name around for now (deprecated), because with the current state of LLVM, it can continue to work just fine.</div><div><br></div><div>When LLVM is changed to *actually* remove all pointer types in its core, then the LLVMBuildGEP function cannot reasonably continue to exist. It simply cannot work, if pointers don't have types, and the type isn't provided. So, remove it.</div></div></blockquote></span><div><br>Yep, this is one we /might/ be able to manage - because we'll probably have to keep typed pointer information around for old bitcode deserialization. (but it does make the API awkward - when we finally do remove LLVMBuildGEP, do we rename LLVMBuildGEP2? Do we leave it there? & then we need LLVMBuildGEP3, etc, as things evolve?))<br><br></div></div></blockquote><div><br></div></span><div>LLVMBuildTypedGEP or something and we can be done with it. When The old way is not supported anymore, LLVMBuildGEP can be removed, and eventually recycled if the need arise.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Also this works for writing, but not for reading - if code was expecting to read IR and assumed that pointers had types and bitcasts were present, etc - it's going to have a Bad Time reading new IR... the APIs wouldn't make any sense (there would be no getPointeeType on PointerType anymore - there would be no Type that could be returned in response to that query)<br><br>That's part of Eric's point, I think, once the API is low level enough, it will churn with every change in LLVM or possible require some heroics to avoid that churn which will slow down LLVM's API velocity (which is somewhere around "ludicrous speed"), which is something we rather like. The only way to make the C API more stable is to make it higher level (see libLTO for an example) so that we can own the migration & shelter users from it through that abstraction. If it's low level, it's going to churn or slow us down (and probably both).</div><br></div></blockquote><div><br></div></span><div>Most of it won't move from one version to another. If something fundamental changes in LLVM from one version to the other, it is not a big deal to update the C API to reflect it. I do not think it is going to need anything heroic to keep it in place.<br></div></div><br></div></div>
</blockquote></div><br></div>