Kristof Beyls via llvm-dev
2017-Dec-18 12:37 UTC
[llvm-dev] [GlobalISel][AArch64] Toward flipping the switch for O0: Please give it a try!
Hi Amara, My reasons for preferring the switch to happen after the release branch is based on the following observations: * As far as I can see, the projects and products following top-of-trunk tend to test much more extensively than the testing that happens for llvm.org<http://llvm.org> releases. I expect that the llvm.org<http://llvm.org> release testing won’t find potential remaining issues, whereas the projects and products following trunk are far more likely to find remaining issues with GlobalISel. Therefore, I think it’s best to give as much time as possible for these projects/products following top-of-trunk to find issues before there’s an llvm.org<http://llvm.org> release with GlobalISel enabled-by-default. * For the projects and products that follow top-of-trunk that I know off, if globalisel-by-default would really break things, it’s possible to disable it within that project/product without end users of it needing to know about this. If for the llvm.org<http://llvm.org> release it would turn out that globalisel has a big issue after release, we’d need to somehow let all users of the release know to disable it by adding a convoluted command line option (‘-mllvm -global-isel=0’?) Combining the 2 observations above, I think it’s better to do the switch shortly after a release branch is taken, rather than just before it. I hope that makes sense? Thanks, Kristof On 15 Dec 2017, at 19:33, Amara Emerson <aemerson at apple.com<mailto:aemerson at apple.com>> wrote: Hi Kristof, We’ve had some more internal discussion and we think that we can, and should, still aim to enable this by default before the release. We have a month of testing time available to shake out critical issues which is normally enough. After the release branch is taken we can also merge in any fixes required during the stabilization period. Thanks, Amara On Dec 15, 2017, at 9:55 AM, Kristof Beyls <kristof.beyls at arm.com<mailto:kristof.beyls at arm.com>> wrote: I don’t know of any further issues preventing us flipping the switch. At this point, I’d aim to flip the switch shortly after the creation of the 6.0.0 release branch, so that GlobalISel can harden a bit more enabled-by-default on trunk before it goes into an LLVM release (presumably 7.0.0 then). Thanks, Kristof On 11 Dec 2017, at 17:08, Amara Emerson <aemerson at apple.com<mailto:aemerson at apple.com>> wrote: As of r320388 we’ve either fixed the blocker bugs or disabled big-endian on GISel, falling back to SDAG. Fixing at least one of the big-endian issues will need use to change the way we handle aggregates, which will take a bit longer (it’s next on my list of things to do). Do we have any other issues preventing us flipping the switch? Amara -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171218/b21fd111/attachment.html>
Amara Emerson via llvm-dev
2017-Dec-18 14:11 UTC
[llvm-dev] [GlobalISel][AArch64] Toward flipping the switch for O0: Please give it a try!
> On Dec 18, 2017, at 12:37 PM, Kristof Beyls <Kristof.Beyls at arm.com> wrote: > > Hi Amara, > > My reasons for preferring the switch to happen after the release branch is based on the following observations: > As far as I can see, the projects and products following top-of-trunk tend to test much more extensively than the testing that happens for llvm.org <http://llvm.org/> releases. I expect that thellvm.org <http://llvm.org/> release testing won’t find potential remaining issues, whereas the projects and products following trunk are far more likely to find remaining issues with GlobalISel. Therefore, I think it’s best to give as much time as possible for these projects/products following top-of-trunk to find issues before there’s an llvm.org <http://llvm.org/> release with GlobalISel enabled-by-default. > For the projects and products that follow top-of-trunk that I know off, if globalisel-by-default would really break things, it’s possible to disable it within that project/product without end users of it needing to know about this. If for the llvm.org <http://llvm.org/> release it would turn out that globalisel has a big issue after release, we’d need to somehow let all users of the release know to disable it by adding a convoluted command line option (‘-mllvm -global-isel=0’?) > Combining the 2 observations above, I think it’s better to do the switch shortly after a release branch is taken, rather than just before it. >I wasn’t suggesting that we proceed with the full release with GISel enabled by default if there are serious issues, I was more saying that we have additional time during the RC period to test further on trunk, and then merge in fixes into the RC. Worst case is that we back out the change completely but I doubt it’ll get to that stage. I do agree that trunk sees more of the testing coverage. If one month isn’t enough, what would have been the cut off point? Thanks, Amara> I hope that makes sense? > > Thanks, > > Kristof > > >> On 15 Dec 2017, at 19:33, Amara Emerson <aemerson at apple.com <mailto:aemerson at apple.com>> wrote: >> >> Hi Kristof, >> >> We’ve had some more internal discussion and we think that we can, and should, still aim to enable this by default before the release. We have a month of testing time available to shake out critical issues which is normally enough. After the release branch is taken we can also merge in any fixes required during the stabilization period. >> >> Thanks, >> Amara >> >>> On Dec 15, 2017, at 9:55 AM, Kristof Beyls <kristof.beyls at arm.com <mailto:kristof.beyls at arm.com>> wrote: >>> >>> I don’t know of any further issues preventing us flipping the switch. >>> At this point, I’d aim to flip the switch shortly after the creation of the 6.0.0 release branch, so that GlobalISel can harden a bit more enabled-by-default on trunk before it goes into an LLVM release (presumably 7.0.0 then). >>> >>> Thanks, >>> >>> Kristof >>> >>>> On 11 Dec 2017, at 17:08, Amara Emerson <aemerson at apple.com <mailto:aemerson at apple.com>> wrote: >>>> >>>> As of r320388 we’ve either fixed the blocker bugs or disabled big-endian on GISel, falling back to SDAG. Fixing at least one of the big-endian issues will need use to change the way we handle aggregates, which will take a bit longer (it’s next on my list of things to do). >>>> >>>> Do we have any other issues preventing us flipping the switch? >>>> >>>> Amara >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171218/b7a9e6d0/attachment.html>
Kristof Beyls via llvm-dev
2017-Dec-18 15:25 UTC
[llvm-dev] [GlobalISel][AArch64] Toward flipping the switch for O0: Please give it a try!
On 18 Dec 2017, at 15:11, Amara Emerson <aemerson at apple.com<mailto:aemerson at apple.com>> wrote: On Dec 18, 2017, at 12:37 PM, Kristof Beyls <Kristof.Beyls at arm.com<mailto:Kristof.Beyls at arm.com>> wrote: Hi Amara, My reasons for preferring the switch to happen after the release branch is based on the following observations: * As far as I can see, the projects and products following top-of-trunk tend to test much more extensively than the testing that happens for llvm.org<http://llvm.org/> releases. I expect that the llvm.org<http://llvm.org/> release testing won’t find potential remaining issues, whereas the projects and products following trunk are far more likely to find remaining issues with GlobalISel. Therefore, I think it’s best to give as much time as possible for these projects/products following top-of-trunk to find issues before there’s an llvm.org<http://llvm.org/> release with GlobalISel enabled-by-default. * For the projects and products that follow top-of-trunk that I know off, if globalisel-by-default would really break things, it’s possible to disable it within that project/product without end users of it needing to know about this. If for the llvm.org<http://llvm.org/> release it would turn out that globalisel has a big issue after release, we’d need to somehow let all users of the release know to disable it by adding a convoluted command line option (‘-mllvm -global-isel=0’?) Combining the 2 observations above, I think it’s better to do the switch shortly after a release branch is taken, rather than just before it. I wasn’t suggesting that we proceed with the full release with GISel enabled by default if there are serious issues, I was more saying that we have additional time during the RC period to test further on trunk, and then merge in fixes into the RC. Worst case is that we back out the change completely but I doubt it’ll get to that stage. I do agree that trunk sees more of the testing coverage. If one month isn’t enough, what would have been the cut off point? Thanks, Amara Yeah, I agree that the time needed before the next release happens when switching is debatable. After looking it up, I see that the final release tag is planned for no earlier than 21 February 2018, so we’d indeed have a bit of time to revert it on the release branch if serious issues were discovered. Seeing the actual release date is that far out, I don’t have strong objections to flipping the switch now if others want to press on with it. Thanks, Kristof -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171218/cef96039/attachment.html>