[llvm-dev] Changes to the Developer Policy / IR Backwards Compatibility

[Mehdi Amini via llvm-dev]

> On Oct 8, 2016, at 10:41 AM, Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> 
> On Fri, Oct 7, 2016 at 11:57 PM Moritz Angermann via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi,
> 
> I’ve noted some change in wording on the current (4.0) developer policy[1],
> compared to the 3.9 developer policy[2]. Specifically the part about IR
> Backwards Compatibility.
> 
> The change from 3.9 to 4.0 is the following:
> 
>   - The textual format is not backwards compatible. We don’t change it too often, but there are no specific promises.
>   - Additions and changes to the IR should be reflected in test/Bitcode/compatibility.ll.
> - - The bitcode format produced by a X.Y release will be readable by all following X.Z releases and the (X+1).0 release.
> + - The current LLVM version supports loading any bitcode since version 3.0.
>   - 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.
>   - 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.
>   - Debug metadata is special in that it is currently dropped during upgrades.
>   - 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.
> 
> This raises the following question for me: does this imply that bitcode generated by 4.X won’t necessarily be as
> stable as it was for the 3.X series, specifically that the backwards compatability guarantee will be scraped in
> LLVM 4.0+?
> 
> 
> 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.


To pile-up in case it is not clear: the intent is to *extend* the compatibility.

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.

— 
Mehdi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161008/e18811ef/attachment.html>