Re: [PATCH], PR 68404 patch #3 (fix earlyclobber problem on power8 fusion)

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

On Thu, Feb 11, 2016 at 04:14:59PM -0800, David Edelsohn wrote:
> On Thu, Feb 11, 2016 at 1:43 PM, Michael Meissner
> <meissner@linux.vnet.ibm.com> wrote:
> > After looking at Bernd Schmidt and Jakub Jelinek's suggestions, I came to
> > conclusion that earlyclobber was not needed in this case, and I removed it.  I
> > bootstrapped the compiler using profiledbootstrap and lto options and it
> > succeeded build and running make check.  Just to be sure, I also did a
> > profiledbootstrap with LTO and -O3 and it built fine.  Is it ok to install
> > these patches?
> >
> > I decided to keep the changes to the testsuite explicitly passing the fusion
> > switches, rather than letting -mtune=power8/power9 set them, but I can be
> > persuaded to restore the 3 tests to the way they were before February 9th.
> >
> > [gcc]
> > 2016-02-11  Michael Meissner  <meissner@linux.vnet.ibm.com>
> >
> >         PR target/68404
> >         * config/rs6000/predicates.md (fusion_gpr_addis): Revert
> >         2016-02-09 change.
> >
> >         * config/rs6000/rs6000.md (fusion_gpr_load_<mode>): Remove
> >         earlyclobber from target.  Use wF constraint for fused memory
> >         address.
> >         (fusion_gpr_<P:mode>_<GPR_FUSION:mode>_load): Likewise.
> >
> > [gcc/testsuites]
> > 2016-02-11  Michael Meissner  <meissner@linux.vnet.ibm.com>
> >
> >         PR target/68404
> >         * gcc.target/powerpc/fusion.c: Do not assume that -mtune=power8
> >         sets -mpower8-fusion or -mtune=power9 sets -mpower9-fusion.
> >         * gcc.target/powerpc/fusion2.c: Likewise.
> >         * gcc.target/powerpc/fusion3.c: Likewise.
> >
> > Since gcc 5.0 also has the earlyclobber in the pattern, I would like to apply
> > the same change to gcc 5.x (after testing of course), even though we haven't
> > yet run into the problem with GCC 5.x.  Is this ok as well?
> 
> This is okay for trunk and GCC 5 branch.
> 
> Did you test the patch with the first patch reverted?  The first patch
> also was correct and fixed a problem, but it also allows this
> underlying bug to appear more prominently.  I want to ensure that the
> patch was compared with a version of the compiler that elicited the
> failure symptoms.

The patch to predicates.md reverts the original change that I made on February
9th.  I did sync up the trunk to a newer revision, and I can go through a build
without the rs6000.md patch to show that the rs6000.md patch is the one that
fixes the problem if you prefer.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797