<div dir="ltr">Do you have a suggested wording? I think the wording is pretty clear as to what you can expect. We're not going to make a huge number of promises for forward compatibility, however, we can say that we'll give a good lead time if something is going to change.<div><br></div><div>Thanks!<br><div><br></div><div>-eric<br><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 8, 2016 at 7:53 PM Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com">moritz.angermann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="gmail_msg"><br><br class="gmail_msg"><br>thank you for clearing that up! Maybe it’s worth to extend the wording then?<br class="gmail_msg"><br><br class="gmail_msg"><br>I’m essentially generating bitcode without using the llvm bitcode writer, and<br class="gmail_msg"><br>hence have some interest in knowing what compatibility the bitcode I generate<br class="gmail_msg"><br>today will provide, and when the bitcode generator will need to be adapted.<br class="gmail_msg"><br><br class="gmail_msg"><br>The basic reasoning behind this is, that the textual ir is rather unstable and<br class="gmail_msg"><br>the bitcode ir is more stable and compatible across a larger set of llvm<br class="gmail_msg"><br>versions.<br class="gmail_msg"><br><br class="gmail_msg"><br>If there’s going to be 4.0 followed by 5.0, will 5.0 be able to read all bc<br class="gmail_msg"><br>from 3.0 as well? From the old old documentation I felt assured that generating<br class="gmail_msg"><br>bc as of 3.7 or 3.8, would still be readable by 4.0. However with the current<br class="gmail_msg"><br>documentation, it’s not clear to me when I can expect the bitcode generated<br class="gmail_msg"><br>will stop working.<br class="gmail_msg"><br><br class="gmail_msg"><br>Also, will there be a 5.X series? Or will there be 5.0 be followed by 6.0?<br class="gmail_msg"><br><br class="gmail_msg"><br>Thanks again!<br class="gmail_msg"><br><br class="gmail_msg"><br>Cheers,<br class="gmail_msg"><br> Moritz<br class="gmail_msg"><br><br class="gmail_msg"><br>> On Oct 9, 2016, at 3:07 AM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" class="gmail_msg" target="_blank">mehdi.amini@apple.com</a>> wrote:<br class="gmail_msg"><br>><br class="gmail_msg"><br>><br class="gmail_msg"><br>>> On Oct 8, 2016, at 10:41 AM, Eric Christopher via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>><br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> On Fri, Oct 7, 2016 at 11:57 PM Moritz Angermann via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg"><br>>> Hi,<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> I’ve noted some change in wording on the current (4.0) developer policy[1],<br class="gmail_msg"><br>>> compared to the 3.9 developer policy[2]. Specifically the part about IR<br class="gmail_msg"><br>>> Backwards Compatibility.<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> The change from 3.9 to 4.0 is the following:<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>>   - The textual format is not backwards compatible. We don’t change it too often, but there are no specific promises.<br class="gmail_msg"><br>>>   - Additions and changes to the IR should be reflected in test/Bitcode/compatibility.ll.<br class="gmail_msg"><br>>> - - The bitcode format produced by a X.Y release will be readable by all following X.Z releases and the (X+1).0 release.<br class="gmail_msg"><br>>> + - The current LLVM version supports loading any bitcode since version 3.0.<br class="gmail_msg"><br>>>   - After each X.Y release, compatibility.ll must be copied to compatibility-X.Y.ll. The corresponding bitcode file should be assembled using the X.Y build and committed as compatibility-X.Y.ll.bc.<br class="gmail_msg"><br>>>   - Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR.<br class="gmail_msg"><br>>>   - Debug metadata is special in that it is currently dropped during upgrades.<br class="gmail_msg"><br>>>   - Non-debug metadata is defined to be safe to drop, so a valid way to upgrade it is to drop it. That is not very user friendly and a bit more effort is expected, but no promises are made.<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> This raises the following question for me: does this imply that bitcode generated by 4.X won’t necessarily be as<br class="gmail_msg"><br>>> stable as it was for the 3.X series, specifically that the backwards compatability guarantee will be scraped in<br class="gmail_msg"><br>>> LLVM 4.0+?<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> The intent here was that while typically a major revision would enable a bitcode break - we actually didn't do that this time and so we're just keeping compatibility even with the major version number change.<br class="gmail_msg"><br>><br class="gmail_msg"><br>><br class="gmail_msg"><br>> To pile-up in case it is not clear: the intent is to *extend* the compatibility.<br class="gmail_msg"><br>><br class="gmail_msg"><br>> Also worth mentioning that there won’t be any 4.X series: 4.0 is scheduled for January, and the summer release will be 5.0.<br class="gmail_msg"><br>><br class="gmail_msg"><br>> —<br class="gmail_msg"><br>> Mehdi<br class="gmail_msg"><br>><br class="gmail_msg"><br>><br class="gmail_msg"><br><br class="gmail_msg"><br></blockquote></div></div></div></div>