llvm dev - Oct 2016 - Changes to the Developer Policy / IR Backwards Compatibility

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+?

Cheers,
 Moritz

--
[1]: http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
[2]:
http://llvm.org/releases/3.9.0/docs/DeveloperPolicy.html#ir-backwards-compatibility

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>

> 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>