Re: PATCH: Fix ll/sc for mips (take 3)

[Justin Carlson <justinca at ri dot cmu dot edu>]

On Sat, 2002-02-02 at 15:03, H . J . Lu wrote:
> On Sat, Feb 02, 2002 at 01:53:23PM -0500, Justin Carlson wrote:
> > 
> > Actually, regardless of whether modern cpus implement it, I'd argue that
> > avoiding the branch likely is a good idea for 2 reasons:
> > 
> > 1)  In the latest MIPS specs (mips32 and mips64) branch likelies have
> > officially been deprecated as probable removals from the architecture in
> > the not-too-distant future.
> > 
> > 2)  More importantly, most implementations don't use any sort of dynamic
> > branch prediction on branch likelies.  They predict taken, always, since
> > that's the specified intent (it's a branch *likely* to be taken).  For
> > most spin locks, the normal behaviour is a fall through, not taking that
> > branch, so you're inflicting a branch mispredict penalty on every  lock
> > grabbed without contention.  Even for locks which the general case is
> > contention, giving the processor branch predictor a chance to learn that
> > is a Good Idea.
> > 
> 
> Does everyone agree with this? If yes, I can make a patch not to use
> branch likely. But on the other hand, "gcc -mips2" will generate code
> using branch likely. If branch likely doesn't buy you anything, 
> shouldn't we change gcc not to generate branch likely instructions?
> 

I know of at least one internal version of gcc which already has been
hacked to remove generation of branch likely instructions.  It actually
helped performance a bit because gcc has (possibly had, this was 6-9
months ago) the bad habit of generating code like this:

beqzl   $1, next
 daddiu $2, $3, 1
next:
...

This looks like a nice, compact way to do a conditional move.  In
practice, it's a horrendous idea due to the lack of consideration of the
branch prediction.  It's easier to tell the compiler not to generate
branch likelies than to try to fix the code generation for this case. 
:)

Also, I didn't say branch likely doesn't buy you anything; there are
situations where it works well.  Looking at the spin_lock code, though,
this isn't one of them.  The cases where it is a win are far enough
between that my personal practice is to generally avoid them.

-Justin