[Top] [All Lists]

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

To: Kumba <>
Subject: Re: [PATCH]: R10000 Needs LL/SC Workaround in Gcc
From: Richard Sandiford <>
Date: Sat, 01 Nov 2008 17:41:30 +0000
Cc:, Linux MIPS List <>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:from:to:mail-followup-to:cc :subject:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=7ukXR8OVOckUiENM3ccYv+2tSTaUC+BTCGjwUT9tAbM=; b=PqbWDGhaNNqbEKrHTOyOGnqWItaeFvMWltdq8G5x9o5OPs/ujMbkxJAa5Ypm+kYNQi qSCh2C7n/sXpGT/8ABYCbxq0uF1bDHNvUUFj2ReYh/nRxtjln+tEuNBCSB8IDNYImvxB Xdbgv9qvgSTqaSDNA4rhhaB+sD5BSN4U3Fvnk=
Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=from:to:mail-followup-to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=VIjIGPOKxXHRReenwH77Fj9fA7slyW/IOzBGeIlgLIIlvvly/OLvqV6uwQD4fRU1go MMU7JC7+H4PmZeq//YbY4IkV0EDE/Boz+Uhi2T8nZL8QuhgXYPR13VyuznLEyiBoN7FJ 1STWjWYfCfV/s4mOtmkWU5kUz1ovSZZCa6lS0=
In-reply-to: <> ('s message of "Sat\, 01 Nov 2008 03\:30\:49 -0400")
Mail-followup-to: Kumba <>,, Linux MIPS List <>,
Original-recipient: rfc822;
References: <> <>
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (gnu/linux)
Kumba <> 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 
>> (, 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.


<Prev in Thread] Current Thread [Next in Thread>