This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Remove SLOW_BYTE_ACCESS from get_best_mode
On Sun, Sep 10, 2006 at 08:37:54PM -0700, Dale Johannesen wrote:
>
> >I tried this patch on
> >Prescott, Nocona, Core and Core 2. There are no regressions in gcc
> >testsuites nor negative performance impact on SPEC CPU 2K.
>
> From the documentation, it certainly appears that 1 is the right
> setting for
> SLOW_BYTE_ACCESS on, at least, all current x86 chips. The odd thing
> is the Spec regressions you reported on Nocona. This probably means
With my new patch, I got these on Nocona with gcc 4.2:
-O2 -O2 + my patch
164.gzip 1013 1017 0.394867%
175.vpr 1109 1103 -0.541028%
176.gcc 1500 1511 0.733333%
181.mcf 822 814 -0.973236%
186.crafty 1548 1548 0%
197.parser 960 960 0%
252.eon 1735 1738 0.172911%
253.perlbmk 1643 1642 -0.0608643%
254.gap 1683 1680 -0.178253%
255.vortex 1700 1706 0.352941%
256.bzip2 1300 1300 0%
300.twolf 1567 1615 3.06318%
Est. SPECint_base2000 1342 1345 0.223547%
168.wupwise 1842 1839 -0.162866%
171.swim 2352 2333 -0.807823%
172.mgrid 1157 1163 0.518583%
173.applu 1424 1415 -0.632022%
177.mesa 1512 1517 0.330688%
178.galgel 2637 2665 1.06181%
179.art 2165 2406 11.1316%
183.equake 2083 2085 0.0960154%
187.facerec 1448 1452 0.276243%
188.ammp 1431 1478 3.28442%
189.lucas 2099 2106 0.333492%
191.fma3d 1615 1609 -0.371517%
200.sixtrack 684 684 0%
301.apsi 1427 1424 -0.210231%
Est. SPECfp_base2000 1623 1639 0.985829%
I didn't see any regressions.
> we should look at the places where SLOW_BYTE_ACCESS is being used;
> if it's being misused[*] that may affect other targets as well as x86.
> You've evaluated the place in stor-layout.c and that's not the problem.
> There are only 2 other places, both in dojump.c.
>
I don't guite understand how SLOW_BYTE_ACCESS is used in dojump.c. That
is why my new patch doesn't change dojump.c at all and uses a new macro
for stor-layout.c
H.J.