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

[Eric Christopher via llvm-dev]

On Fri, Oct 7, 2016 at 11:57 PM Moritz Angermann via llvm-dev <
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.

Thanks!

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