Re: #define SLOW_BYTE_ACCESS in i386.h

["H. J. Lu" <hjl at lucon dot org>]

On Fri, Sep 01, 2006 at 12:24:18PM -0700, Hui-May Chang wrote:
> 
> On Sep 1, 2006, at 11:26 AM, H. J. Lu wrote:
> 
> >On Fri, Sep 01, 2006 at 11:03:31AM -0700, Eric Christopher wrote:
> >>Hui-May Chang wrote:
> >>>I have a question regarding "#define SLOW_BYTE_ACCESS" in i386.h.  
> >>>It is
> >>>used in "get_best_mode" routine which finds the best mode to use  
> >>>when
> >>>referencing a bit field. It is currently set to 0. If it is set it  
> >>>to 1,
> >>>it means "accessing less than a word of memory is no faster than
> >>>accessing a word of memory".  I experimented with it and observed  
> >>>great
> >>>performance improvement. It is set to 1 for some other  
> >>>configurations
> >>>(e.g., rs6000, pa, ia64). Is it always a win to set it? Is it  
> >>>better to
> >>>set it for certain i386 architectures?
> >>>
> >>
> >>I'll bet that it's probably advantageous to set it for a couple of
> >>reasons in the new chips at least:
> >>
> >>1) You avoid the problem that got you here of large bitfields needing
> >>shift/insert operations
> >>
> >>2) You avoid length changing since you're mostly operating on  
> >>things in
> >>word mode.
> >>
> >>However, I'm not an expert on the chip so I'd suggest posting a small
> >>testcase that shows #1 for people and the resultant code  
> >>differences so
> >>they can see the difference. Hopefully someone with more intel
> >>experience (like HJ or Jan) can comment on whether or not this is a  
> >>good
> >>general idea for the processor.
> >>
> >
> >I tried this patch and enabled it for Conroe and Nocona. It doesn't
> >have much impact on SPEC CPU 2000 on Conroe and it seems bad on  
> >Nocona.
> >Maybe we should add -mslow-byte-access to investigate it further.
> >
> >

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?


H.J.