This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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: Fix ll/sc for mips (take 3)


>>>>> "Justin" == Justin Carlson <justinca@ri.cmu.edu> writes:

 Justin> On Sat, 2002-02-02 at 15:03, H . J . Lu wrote:
 >> 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?
 >> 

 Justin> I know of at least one internal version of gcc which already
 Justin> has been hacked to remove generation of branch likely
 Justin> instructions. 

More precisely (if you're looking at the same one I was) -- it has a
target processor type check that disables it for those CPUs where it
is known to be not a good idea.

 Justin> Also, I didn't say branch likely doesn't buy you anything;
 Justin> there are situations where it works well.  Looking at the
 Justin> spin_lock code, though, this isn't one of them.  

I agree, and I think that point was missed.  Independent of whether a
particular processor (MIPS or otherwise) has the concept of "branch
likely", the design rule of spinlocks is that you try to avoid
spinning (i.e., avoid lock contention) in the system design.  So for
that particular construct, the right answer is "branch not likely".

     paul


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