All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.