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

[Eric Christopher via llvm-dev]

Do you have a suggested wording? I think the wording is pretty clear as to
what you can expect. We're not going to make a huge number of promises for
forward compatibility, however, we can say that we'll give a good lead time
if something is going to change.

Thanks!

-eric

On Sat, Oct 8, 2016 at 7:53 PM Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Hi,
>
>
>
> thank you for clearing that up! Maybe it’s worth to extend the wording
> then?
>
>
>
> I’m essentially generating bitcode without using the llvm bitcode writer,
> and
>
> hence have some interest in knowing what compatibility the bitcode I
> generate
>
> today will provide, and when the bitcode generator will need to be adapted.
>
>
>
> The basic reasoning behind this is, that the textual ir is rather unstable
> and
>
> the bitcode ir is more stable and compatible across a larger set of llvm
>
> versions.
>
>
>
> If there’s going to be 4.0 followed by 5.0, will 5.0 be able to read all bc
>
> from 3.0 as well? From the old old documentation I felt assured that
> generating
>
> bc as of 3.7 or 3.8, would still be readable by 4.0. However with the
> current
>
> documentation, it’s not clear to me when I can expect the bitcode generated
>
> will stop working.
>
>
>
> Also, will there be a 5.X series? Or will there be 5.0 be followed by 6.0?
>
>
>
> Thanks again!
>
>
>
> Cheers,
>
>  Moritz
>
>
>
> > On Oct 9, 2016, at 3:07 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> >
>
> >
>
> >> 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> 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/20161009/618650fa/attachment.html>