Re: [PATCH, powerpc] PR 58160 -- fix power8 gpr load fusion to be safer

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

On Thu, Aug 15, 2013 at 01:18:00AM +0200, Jakub Jelinek wrote:
> On Wed, Aug 14, 2013 at 06:55:26PM -0400, Michael Meissner wrote:
> > In running the spec 2006 testsuite with several options, we discovered that
> > -mtune=power8 (which turns on the -mpower8-fusion option) has a segmentation
> > fault in two benchmarks:
> > 
> > 403.gcc when built with -O2 -mcpu=power7 -mtune=power8 -m32
> > 435.gromacs when built with -O3 -funroll-loops -mcpu=power7 -mtune=power8 -m32
> > 
> > In the gcc case, I tracked it down to the fusion op in the function
> > strength_reduce in the file loop.c.  It was wanting to use the result of the
> > addis instruction after the loop.
> 
> Reminds me of PR57281/PR57300 on i?86/s390, where it was trying to check for
> dead registers in splitters instead of peephole, but otherwise was similar.
> Peephole2 is the pass which guarantees the note problem is computed and you
> can use peep2_reg_dead_p etc. safely, you can't use that in peephole or
> splitter patterns, and as computing it is expensive, it can't be easily
> available in too many passes.

Yep, as I was looking at the register dumps, I remembed having problems in the
past with peepholes and live/dead information was not up to date.

The real solution is to widen what valid addresses are and fix them up in
secondary reload, which I'm attempting to do, but that will take longer to get
done.

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