On Wed, Aug 3, 2016 at 6:59 PM, Peter Bergner <berg...@vnet.ibm.com> wrote: > On 8/2/16 3:17 PM, Peter Bergner wrote: >> >> Now that Vlad has fixed PR69847, which was the last problem holding the >> rs6000 port from switching from reload to LRA, we are ready to flip the >> switch. >> >> Is the following ok once bootstrap/regtesting on both LE and BE >> (32 & 64 regtesting) comes out clean? > > > So we have two "regressions": > > +FAIL: gcc.target/powerpc/bool3-p7.c scan-assembler-not [ \\t]xxlnor > +FAIL: gcc.target/powerpc/bool3-p8.c scan-assembler-not [ \\t]xxlnor > > > Looking into these "failures", they show up because when we enable > LRA, we also implicitly enable -mvsx-timode and these failures are > due to -mvsx-timode. The same test cases fail when we use -mvsx-timode > with reload. > > I'll note that these failures are not code correctness bugs, but > performance bugs. I plan to open a bugzilla to track the fixing > of these failures. > > My question, is since these failures are not due to LRA, do we > want to consider the switch to LRA ok to commit or do we want to > wait until the -mvsx-timode performance bug is fixed?
Peter, Please go ahead and commit the LRA switch patch. Please open a Bugzilla for the rs6000 backend about the vsx-timode performance regression. The vsx-timode regression needs to be fixed for GCC 7. Thanks, David