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
next prev parent 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.