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 20:00:57 -0400 [thread overview]
Message-ID: <490CEDB9.6030600@gentoo.org> (raw)
In-Reply-To: <87tzargrn4.fsf@firetop.home>
Richard Sandiford wrote:
>
> To be clear, the first option above was to check -- in mips_override_options --
> that -mfix-r10000 is only used in cases where -mbranch-likely is in effect.
> If we pick that option, it would be an error to use -mfix-r10000 in
> other cases, and any code protected by TARGET_FIX_R10000 would be free
> to use branch-likely instructions. (Actually, we should use sorry()
> instead of error() to report something like this.)
[snip]
> That's the second option above, yes. In other words, -mfix-r10000
> would support both -mbranch-likely and -mno-branch-likely, and act
> accordingly.
So do I need to worry about modifying the asm templates at all? Or is that only
needed if pursuing option #2?
The branch-likely stuff is only going to work for MIPS-II or higher targets. In
the odd (but possible) cases where MIPS-I might be used with -mfix-r10000, I
assume we'll still have to emit 28 nops prior to a beq/beqz instruction. Is
this already taken care of someplace?
> ...that's a good question. My take is "no". I don't think we want
> -mfix-r10000 to enable branch-likely instructions in cases where
> it isn't necessary for R10000 errata. If we take the first option,
> we can simply raise an error if:
Hmm, okay. Might this work to enable -mbranch-likely if -mfix-r10000? (Kind of
guessing by looking at other segments of code).
if ((target_flags_explicit & MASK_BRANCHLIKELY) == 0)
{
if (ISA_HAS_BRANCHLIKELY
&& (optimize_size
|| (!(target_flags_explicit & MASK_FIX_R10000) == 0)
|| (mips_tune_info->tune_flags & PTF_AVOID_BRANCHLIKELY) == 0))
target_flags |= MASK_BRANCHLIKELY;
else
target_flags &= ~MASK_BRANCHLIKELY;
}
My understanding so far for -mfix-r10000:
- Gets enabled if -march=r10000 is passed (done)
- Enable -mbranch-likely if not already enabled on >= MIPS-II (working on)
- Emits beqzl in the asm templates if enabled and >= MIPS-II (unsure)
- Emits 28 nops prior to beq/beqz if enabled and == MIPS-I (unsure)
- Ditto for asm templates (unsure)
- Documentation (not done)
Missing anything?
> Yeah, I was wondering that too. I did a search, but couldn't
> find anything.
It seems we just need to use nop only and not worry about ssnop.
--
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-02 0:02 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
2008-11-01 19:42 ` Richard Sandiford
2008-11-02 0:00 ` Kumba [this message]
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=490CEDB9.6030600@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