This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, powerpc] PR 58160 -- fix power8 gpr load fusion to be safer
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, gcc-patches at gcc dot gnu dot org, dje dot gcc at gmail dot com
- Date: Thu, 15 Aug 2013 01:18:00 +0200
- Subject: Re: [PATCH, powerpc] PR 58160 -- fix power8 gpr load fusion to be safer
- References: <20130814225526 dot GA7648 at ibm-tiger dot the-meissners dot org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.