Mehdi Amini via llvm-dev
2016-Oct-08 19:07 UTC
[llvm-dev] Changes to the Developer Policy / IR Backwards Compatibility
> 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>
Moritz Angermann via llvm-dev
2016-Oct-09 02:53 UTC
[llvm-dev] Changes to the Developer Policy / IR Backwards Compatibility
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 > >
Eric Christopher via llvm-dev
2016-Oct-09 02:59 UTC
[llvm-dev] Changes to the Developer Policy / IR Backwards Compatibility
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>
Mehdi Amini via llvm-dev
2016-Oct-09 03:03 UTC
[llvm-dev] Changes to the Developer Policy / IR Backwards Compatibility
> On 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?Patches welcome :)> > I’m essentially generating bitcode without using the llvm bitcode writer,You may be interested in this not-totally-related-but-still thread: http://lists.llvm.org/pipermail/llvm-dev/2016-September/105273.html What’s your motivation? Is it to support a front-end written in another language?> 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?Yes.> 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.From the old documentation, you were also assured that 4.0 will be the last release to read 3.x bitcode.> However with the current > documentation, it’s not clear to me when I can expect the bitcode generated > will stop working.Because we have no plan to drop support for it at that time, we just wrote that we support bitcode for every release since 3.0. Does it mean that this will never change? No, we can’t make any guarantee of course. But if it were to change we wouldn’t do it overnight either, and surely we would plan this a few releases ahead.> Also, will there be a 5.X series? Or will there be 5.0 be followed by 6.0?6.0 will follow ~6 months after 5.0 according to the current plan. — Mehdi> > 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 >> >> >