<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 7, 2016 at 11:57 PM Moritz Angermann via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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 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">
  - The textual format is not backwards compatible. We don’t change it too often, but there are no specific promises.<br class="gmail_msg">
  - 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">
  - 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">
  - 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">
  - Debug metadata is special in that it is currently dropped during upgrades.<br class="gmail_msg">
  - 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><br></div><div>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><br></div><div>Thanks!</div><div><br></div><div>-eric </div></div></div>