<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 24, 2015 at 10:18 AM, Vedant Kumar <span dir="ltr"><<a href="mailto:vsk@apple.com" target="_blank">vsk@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Overall I think that the approach Steven was suggesting (and which it seems like Vedant is following) is an improvement over the current state of affairs, though is hardly "exhaustive" (which is part of the confusion in the prevoius discussion; realistically a different approach is needed for being "exhaustive"; but "exhaustive" is not actually a goal for anyone I don't think).<br>
<br>
</span>I agree with you that this approach can’t be perfectly exhaustive. However, I think it does buy us a *pretty* good safeguard for a very reasonable amount of overhead.<br></blockquote><div><br></div><div>Absolutely. The primary thing I can think of that could slip through this approach easily are changes that only have a manifestation at the bitcode level, not in IR. E.g. how operand indices in the bitcode were changed from absolute indices in the function to being relative to the instruction's position. Maybe also add BitCodeFormat.rst to your list of files to diff?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> It would be interesting to collect some empirical data about how much effort this release-to-release work is, and which, if any, existing compatibility problems are caught. Vedant, could you maybe retroactively do the expected release-to-release work for the last couple LLVM revisions and see what you find, and how much effort it is?<br>
<br>
</span>Here’s some data :).<br>
<br>
I think a reasonable way of updating compatibility-N.M.ll is by diff’ing LangRef.rst between the relevant commits and adding coverage for all affected areas. For the 3.6 => 3.7 update, we’d have to add support for;<br>
<br>
    o ‘-‘ signs in identifier names<br>
    o comdat specifiers for global variables<br>
    o function prologues and personalities<br>
    o dereferenceable_or_null(<n>)<br>
    o the convergent, argmemonly, safestack, and thunk attributes<br>
    o the ‘distinct’ metadata keyword<br>
    o the revamped landingpad instruction<br>
<br>
These aren’t the only changes in the LangRef between the two releases, but they strike me as the only salient ones from a bitcode compatibility point-of-view.<br>
<br>
It takes maybe a couple minutes to look over the diff, and maybe an hour to extend the .ll file with the necessary changes. I haven’t caught any compatibility problems (excepting the uselistorder serialization issue I mentioned earlier) — however, this gives us a nice way of avoiding those problems in the first place.<br>
<br>
I only went back one revision. I can pull data from previous revisions if you need more convincing :).<br></blockquote><div><br></div><div>This sounds reasonable.</div><div><br></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">
<span class=""><br>
<br>
> I think that the best way forward for bitcode compatibility is for an interested party to set up a watch in Phabricator over all the bitcode-related parts of the tree, then monitor it like a hawk and ensure that all changes needing tests are tested.<br>
<br>
<br>
</span>I don’t know about this. This seems pretty involved, and the people in charge of it might get bored. It’s unclear if the extra coverage this might achieve is cost-effective.<br>
<span class="HOEnZb"><font color="#888888"><br>
vedant</font></span></blockquote></div><br></div></div>