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 Mon, Sep 11, 2006 at 10:05:45AM -0700, Dale Johannesen wrote:
> On Sep 10, 2006, at 9:54 PM, H. J. Lu wrote:
> >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:
> >
> >Est. SPECint_base2000 1342 1345 0.223547%
> >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
>
> OK, looks like I didn't explain what I'm getting at very well.
> Changing SLOW_BYTE_ACCESS
> would conform to its documented definition; but you said this causes
> regressions in Spec
> (Nocona, right?)
>
> >On Sep 1, 2006, at 1:47 PM, H. J. Lu wrote:
> >175.vpr 1118 1102 -1.43113%
> >300.twolf 1650 1589 -3.69697%
> >Est. SPECint_base2000 1346 1340 -0.445765%
>
> My thinking is that the thing to do is:
> 1: Figure out why changing SLOW_BYTE_ACCESS causes Spec regressions,
> and fix that;
> probably, it's being misused somehow in dojump.c (it's not
> obvious to me what it's doing there either).
My first patch changes SLOW_BYTE_ACCESS to 1 for x86, which affects
both dojump.c and stor-layout.c. I believe that is where the SPEC
regression comes from. My second patch only changes stor-layout.c
leaves dojump.c alone. There is no more SPEC regression.
H.J.