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 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.