This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.   
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]