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

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

On Fri, 2002-02-01 at 22:26, Daniel Jacobowitz wrote:
> On Fri, Feb 01, 2002 at 03:15:13PM -0800, H . J . Lu wrote:
> > On Fri, Feb 01, 2002 at 06:01:26PM -0500, Daniel Jacobowitz wrote:
> > > On Fri, Feb 01, 2002 at 10:29:43AM -0800, H . J . Lu wrote:
> > > > On Fri, Feb 01, 2002 at 12:45:02PM +0100, Maciej W. Rozycki wrote:
> > > > > On Thu, 31 Jan 2002, H . J . Lu wrote:
> > > > > 
> > > > > > > Gas will fill delay slots. Same object codes will be produced, so I
> > > > > > > think you don't have to do that by hand. 
> > > > > > 
> > > > > > It will make the code more readable. We don't have to guess what
> > > > > > the assembler will do. 
> > > > > 
> > > > >  But you lose a chance for something useful being reordered to the slot.
> > > > > That might not necessarily be a "nop".  Please don't forget of indents
> > > > > anyway.
> > > > > 
> > > > 
> > > > Here is a new patch. I use branch likely to get rid of nops. Please
> > > > tell me which indents I may have missed.
> > > 
> > > Can you really assume presence of the branch-likely instruction?  I
> > > don't think so.
> > 

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.

-Justin