<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 8, 2016, at 10:41 AM, Eric Christopher via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Oct 7, 2016 at 11:57 PM Moritz Angermann via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">Hi,<br class="gmail_msg"><br class="gmail_msg">I’ve noted some change in wording on the current (4.0) developer policy[1],<br class="gmail_msg">compared to the 3.9 developer policy[2]. Specifically the part about IR<br class="gmail_msg">Backwards Compatibility.<br class="gmail_msg"><br class="gmail_msg">The change from 3.9 to 4.0 is the following:<br class="gmail_msg"><br class="gmail_msg"> <span class="Apple-converted-space"> </span>- The textual format is not backwards compatible. We don’t change it too often, but there are no specific promises.<br class="gmail_msg"> <span class="Apple-converted-space"> </span>- Additions and changes to the IR should be reflected in test/Bitcode/compatibility.ll.<br class="gmail_msg">- - 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">+ - The current LLVM version supports loading any bitcode since version 3.0.<br class="gmail_msg"> <span class="Apple-converted-space"> </span>- 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"> <span class="Apple-converted-space"> </span>- 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"> <span class="Apple-converted-space"> </span>- Debug metadata is special in that it is currently dropped during upgrades.<br class="gmail_msg"> <span class="Apple-converted-space"> </span>- 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 class="gmail_msg">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">stable as it was for the 3.X series, specifically that the backwards compatability guarantee will be scraped in<br class="gmail_msg">LLVM 4.0+?<br class="gmail_msg"><br class="gmail_msg"></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><br class=""></div><div><br class=""></div><div>To pile-up in case it is not clear: the intent is to *extend* the compatibility.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div></body></html>