The width settings in rs6000_reassociation_width() were chosen to help performance for SPEC CPU in gcc 7. Testing on power8 shows that in gcc 8 (258101) there are now major degradations in CPU2017 int with the default reassociation widths as compared to using --param tree-reassoc-width=1 to disable reassociation. Benchmark 500.perlbench_r -5.98% 502.gcc_r -1.16% 505.mcf_r -12.44% 520.omnetpp_r -39.00% 523.xalancbmk_r -9.78% 525.x264_r -1.76% 531.deepsjeng_r -4.23% 548.exchange2_r -0.66% 557.xz_r -2.04%
This needs to be fixed before GCC 8 release.
That sounds odd... can you try analyzing at least one case (520.omnetpp_r?)? Does reassoc width still help SPEC CPU 2006 (which is what I suppose you used for gcc7 testing?)
Yes I'm digging into this now and omnetpp is at the top of the list. I can see if there is a difference between cpu2006 and 2017 as well. For gcc7 I used 2006 to determine the widths.
This turned out to be a system with a bad clock. The reassociation widths still need to be checked and corrected but the performance differences are mostly in the 0.5% range with just one that is about 2% (xz).
Author: acsawdey Date: Tue Mar 13 16:28:09 2018 New Revision: 258495 URL: https://gcc.gnu.org/viewcvs?rev=258495&root=gcc&view=rev Log: 2018-03-13 Aaron Sawdey <acsawdey@linux.vnet.ibm.com> PR target/84743 * config/rs6000/rs6000.c (rs6000_reassociation_width): Disable parallel reassociation for int modes. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
Updated parallel reassociation widths that give better performance than no parallel reassociation are checked in now so this can be closed.