Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Kumba <kumba@gentoo.org>
To: gcc-patches@gcc.gnu.org
Cc: Linux MIPS List <linux-mips@linux-mips.org>, rdsandiford@googlemail.com
Subject: Re: [PATCH]: R10000 Needs LL/SC Workaround in Gcc
Date: Sat, 01 Nov 2008 14:49:44 -0400	[thread overview]
Message-ID: <490CA4C8.40904@gentoo.org> (raw)
In-Reply-To: <87abcjibsl.fsf@firetop.home>

Richard Sandiford wrote:
> 
> 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.

Does using -mbranch-likely change the output of those specific asm commands that 
my original patch was altering?  Or will -mfix-r10000 need to not only check the 
status of -mbranch-likely and set it if not set, but also need to modify the 
referenced beq/beqzl sets in mips.h?

If so, I assume a test for both TARGET_FIX_R10000 and TARGET_BRANCHLIKELY would 
be needed, and then if TARGET_BRANCHLIKELY doesn't exist, but TARGET_FIX_R10000 
is, insert 28 nops before beq.  Sound correct?


On setting -mbranch-likely, I found what I think is the appropriate section in 
mips.c around Line 13810:

   /* If neither -mbranch-likely nor -mno-branch-likely was given
      on the command line, set MASK_BRANCHLIKELY based on the target
      architecture and tuning flags.  Annulled delay slots are a
      size win, so we only consider the processor-specific tuning
      for !optimize_size.  */
   if ((target_flags_explicit & MASK_BRANCHLIKELY) == 0)
     {
       if (ISA_HAS_BRANCHLIKELY
           && (optimize_size
               || (mips_tune_info->tune_flags & PTF_AVOID_BRANCHLIKELY) == 0))
         target_flags |= MASK_BRANCHLIKELY;
       else
         target_flags &= ~MASK_BRANCHLIKELY;
     }
   else if (TARGET_BRANCHLIKELY && !ISA_HAS_BRANCHLIKELY)
     warning (0, "the %qs architecture does not support branch-likely"
              " instructions", mips_arch_info->name);

I'm kind of thinking that the -mfix-r10000 setting to include -mbranch-likely 
would fit here (Assuming this is what can enable/disable that option via 
MASK_BRANCHLIKELY), but if I'm reading it right, optimizing for size disables 
brach-likely instructions.  Shouldn't -mfix-r10000 override that?

Would an equivalent conditional like this be close?:

       if (ISA_HAS_BRANCHLIKELY
           && ((optimize_size || TARGET_FIX_R10000)
               || (mips_tune_info->tune_flags & PTF_AVOID_BRANCHLIKELY) == 0))


Also, does anyone have a copy of the R10000 Silicon Errata documentation kicking 
around?  Thiemo brought up a point that we may need ssnop instead of nop, but 
I'd need to check the errata for that, and that doesn't seem to exist anywhere 
anymore.  I found an old link to it on MIPS' site, but nothing else.  I've only 
got Vr10000 manuals from SGI and NEC, and they don't seem to cover 
revision-specific errata any.

Thanks!

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org

"The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

  reply	other threads:[~2008-11-01 18:50 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-31  5:00 [PATCH]: R10000 Needs LL/SC Workaround in Gcc Kumba
2008-10-31 14:24 ` Maciej W. Rozycki
2008-11-01  7:30 ` Kumba
2008-11-01 17:41   ` Richard Sandiford
2008-11-01 18:49     ` Kumba [this message]
2008-11-01 19:42       ` Richard Sandiford
2008-11-02  0:00         ` Kumba
2008-11-02 10:00           ` Richard Sandiford
2008-11-03  9:01             ` Kumba
2008-11-03 20:47               ` Richard Sandiford
2008-11-04  0:04                 ` Ralf Baechle
2008-11-04  7:14                 ` Kumba
2008-11-04  9:04                   ` Ralf Baechle
2008-11-04 14:26                     ` Maciej W. Rozycki
2008-11-04 14:31                       ` Ralf Baechle
2008-11-04 14:23                   ` Maciej W. Rozycki
2008-11-08  9:37                   ` Richard Sandiford
2008-11-08 18:20                     ` Markus Gothe
2008-11-10  6:09                     ` Kumba
2008-11-11 23:13                       ` Richard Sandiford
2008-11-11 23:28                         ` Richard Sandiford
2008-11-11 23:40                         ` Maciej W. Rozycki
2008-11-12  7:42                         ` Kumba
2008-11-13 23:10                           ` Richard Sandiford
2008-11-14  8:14                             ` Kumba
2008-11-15 14:28                               ` Richard Sandiford
2008-11-16  7:35                                 ` Kumba
2008-11-02 10:49           ` Maciej W. Rozycki
2008-11-02 11:34             ` Richard Sandiford
2008-11-03 16:51             ` Paul_Koning
2008-11-03 16:51               ` Paul_Koning
2008-11-03 16:59               ` Maciej W. Rozycki
2008-11-03 17:35               ` Ralf Baechle
2008-11-01 20:33     ` Maciej W. Rozycki
2008-11-01 23:45       ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=490CA4C8.40904@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linux-mips@linux-mips.org \
    --cc=rdsandiford@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox