On Tue, Feb 9, 2016 at 9:49 AM, Michael Meissner <meiss...@linux.vnet.ibm.com> wrote: > This bug fixes PR 68404, which created an insn for the fusion operation when > accessing an array with a large constant offset that the downstream passes > (regrenam in particular don't like). Because fusion in general adds so little > to the performance of power8, I just eliminated the compiler from generating > this case for GCC 6. In the GCC 7 timeframe, I likely will revist fusion for > power9 support. I ran a spec 2006 benchmark suite comparing the current > behavior and the fix for PR 68404, and it was in the noise level (mcf was 1% > slower, others ranged from 0.3% slower to 0.4% faster). > > I did a bootstrap build, including a bootstrap profiled build with LTO (which > is how the problem was found) and it was found. I rewrote 2 of the 3 fusion > tests so that it uses fusion from a medium code toc entry instead of accessing > an array element with a constant index over 65536 bytes. > > Is this patch ok to apply? If you would prefer, I can eliminate the code > inside of the fusion_gpr_addis predicate instead of using #if 0. > > [gcc] > 2016-02-08 Michael Meissner <meiss...@linux.vnet.ibm.com> > > PR target/68404 > * config/rs6000/predicates.md (fusion_gpr_addis): Prevent fusing > an ADDIS that adds a pointer to a large constant that sets the > upper16 bits with a load operation. > > [gcc/testsuite] > 2016-02-08 Michael Meissner <meiss...@linux.vnet.ibm.com> > > PR target/68404 > * gcc.target/powerpc/fusion.c: Rewrite test to use TOC fusion > instead accessing a really large arrray. > * gcc.target/powerpc/fusion3.c: Likewise.
Please remove the code entirely, not #if 0. Okay with that change. Thanks, David