Re: [PATCH]: R10000 Needs LL/SC Workaround in Glibc

[Daniel Jacobowitz <dan@debian.org>]

On Sat, Nov 22, 2008 at 11:16:18PM -0500, Kumba wrote:
> Here's try #2.  The gcc-side is already sent in and accepted.  If I'm 
> still missing anything, please let me know!
>
> Joshua Kinard
> Gentoo/MIPS
> kumba@gentoo.org
>
>
> 2008-11-22  Joshua Kinard  <kumba@gentoo.org>
>
>         * ports/sysdeps/mips/bits/atomic.h
> 	(R10K_BEQZ_INSN, R10K_NOPS_INSN): Define depending on ISA.
>         (__arch_compare_and_exchange_xxx_32_int): Replace 'beqz' insn with
> 	R10K_BEQZ_INSN and add R10K_NOPS_INSN.
>         (__arch_compare_and_exchange_xxx_64_int): Likewise
>         (__arch_exchange_xxx_32_int): Likewise
> 	(__arch_exchange_xxx_64_int): Likewise
>         (__arch_exchange_and_add_32_int): Likewise
> 	(__arch_exchange_and_add_64_int): Likewise

Thinking about this...

MIPS I: 28 NOPs is really horrid.  Not so much on this processor if
the code is all in cache, but I guess that older/simpler processors
are going to sit for a number of cycles chewing through those NOPs.
Are distributions still building MIPS I code?  Can we assume that
people who want to run glibc on an R10K can at least get something
for MIPS II?

MIPS II, MIPS III, MIPS IV: Using beqzl does not seem particularly
horrid - although it's still a shame since this branch is in fact
anti-likely.  It will almost never be taken.

Other platforms: !(MIPS II or MIPS III or MIPS IV) is not the same as
(MIPS I)!  Please don't activate this workaround on builds that won't
run on an R10K, like MIPS32.

-- 
Daniel Jacobowitz
CodeSourcery