Re: PATCH: Remove SLOW_BYTE_ACCESS from get_best_mode

[Dale Johannesen <dalej at apple dot com>]

On Sep 10, 2006, at 10:57 AM, H. J. Lu wrote:

> On Fri, Sep 08, 2006 at 11:52:51PM -0700, H. J. Lu wrote:
>
> > Why do we use SLOW_BYTE_ACCESS to control bit field access? Bit field
> > currently is implemented as unsigned int, at least for x86. Accessing
> > bit field as 32bit is always faster unless 4 byte accesses are
> > much faster one 32bit access, which is very unlikely will be true for
> > x86 in any circumstances. Is this a leftover from the old bit field
> > implementation?
>
> I don't understand why we use byte instruction to access 32bit field.
> There may be some hardwares where 4 byte accesses are faster than one
> 32bit access. But I am not aware any x86 one.

fwiw, I have an x86 manual from 1987, it describes byte and 32-bit  
accesses
as equally fast.  I haven't kept track of every variant between then  
and now, though.

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

[*](Perhaps someone was misled by its name into thinking it means
"byte accesses are slower than word accesses", which it doesn't.   
Somebody
with more gcc experience than I already made that mistake.  I'm  
planning  a
patch to rename it to something more descriptive, but not in stage  
3...how does
FAST_WORD_ACCESS sound?)