[PATCH]: R10000 Needs LL/SC Workaround in Gcc

[Richard Sandiford]

Kumba <kumba@gentoo.org> writes:
> Kumba wrote:
>> The attached patch adds a workaround to have gcc emit branch likely 
>> instructions (beqzl) in atomic operations for R10000 CPUs.  This is 
>> because revisions of this CPU before 3.0 misbehave, while revisions 2.6 
>> and earlier will deadlock.  This issue has been noted on SGI IP28 
>> (Indigo2 Impact R10000) systems and SGI IP27 Origin systems.
>> 
>> After creating a patch to glibc based off of Debian Bug #462112 
>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462112), it was 
>> suggested by David Daney that a similar patch be created for GCC.
>> 
>> Feedback would be welcome on any suggestions for improving this patch 
>> (please CC, as I'm not subscribed to the ML).
>> 
>> Thanks!
>
> Oops, typo in my first patch.  Stray parenthesis around the macro
> check.  Fixed patch is included.
>
> I'm wondering whether this should be limited to _MIPS_ARCH_R10000,
> though.  Maybe _MIPS_ARCH_MIPS4 instead, because the R10000 is at
> minimum, a MIPS-IV CPU, and there might be cases where a userland
> compiled with -march=mips4 could get used instead of one optimized for
> -march=r10000?
>
> Or would MIPS-II be better, which is when the branch likely
> instruction was added?

As Maciej said, this should really be controlled by an -mfix-r10000
command-line option, not by the _MIPS_ARCH_* macro.  (In this context,
_MIPS_ARCH_* is a property of the compiler that you're using to build
gcc itself.)

There are two ways we could handle this:

  - Make -mfix-r10000 require -mbranch-likely.  (It mustn't _imply_
    -mbranch-likely.  It should simply check that -mbranch-likely is
    already in effect.)

  - Make -mfix-r10000 insert nops when -mbranch-likely is not in effect.

Richard