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: Mon, 03 Nov 2008 04:01:22 -0500	[thread overview]
Message-ID: <490EBDE2.6010709@gentoo.org> (raw)
In-Reply-To: <87prleh2hc.fsf@firetop.home>

Richard Sandiford wrote:

(Quoting out of order)

> 
> I feel we're talking at cross-purposes, so just to be clear:

Not really cross-purposes.  I'm just rather new to patching something big like a 
full-blown, multi-target compiler with 20 years of history to it.  Mostly trying 
to get an appropriate understanding of your two options so I can work the logic 
out in my head and know how to go about attacking this.

This is a step up from writing a md file for processor scheduling :)


>    2) Implement both (a) and (b).  In this case, any gcc code guarded
>       by TARGET_FIX_R10000 would need to check whether branch-likely
>       instructions are available.  If they are, we can use either
>       workaround (a) or workaroudn (b).  If they aren't, we must
>       use workaround (b).

I think it's better to target this path.  While it's probably an extremely rare 
case, because this problem only affects a specific set of processor revisions, 
triggering a problem only noticed (so far) on SGI machines running Linux, I tend 
to err on the side of caution and think it's probably a good idea to do it right 
the first time.

Also, Murphy's Law.


> You need to modify the asm templates whatever you do.

This is what has me a little perplexed.  The asm templates are #define macros, 
and it's kind of dawned on me that my attempts made so far to correct the errata 
has me using preprocessor macros that are going to get translated into something 
else when gcc itself is compiled, rather than gcc changing what it outputs based 
on the flags we send it.

So I'm assuming that, poking around in the sync.md file some, the better 
approach might be to pass an extra argument to these atomic macros as they're 
evaluated in sync.md.  This extra argument being the resultant branch likely 
instruction:

	- If -mfix-r10000 isn't needed or -mbranch-likely isn't called,
	  "beq" gets passed in.
	- If -mfix-r10000 is called, and ISA_HAS_BRANCHLIKELY is false,
	  pass in 28 nops plus "beq" (is there some kind of macro that can
	  expand a single nop 28 times?).
	- If -mfix-r10000 is called and ISA_HAS_BRANCHLIKELY is true
	  and -mno-branch-likely was not called, then pass in the beqzl
	  instruction.

I think that's all the relevant combinations.  It's also probably a good idea 
too to determine the value to pass as the extra argument before the atomic macro 
is called.

Is this kind of check something that would need to be done in the md file 
directly, referencing the various macros as needed, or would it need to be 
defined as a function in mips.c and called inline in sync.md, returning a string 
value to the function as it exists?  Or is there a better way?


> Yes, provided that you never override an explicit -mfix-r10000 or
> -mno-fix-r10000.

I copied the same code for R4000 and R4400 for this:

   /* Default to working around R10000 errata only if the processor
      was selected explicitly.  */
   if ((target_flags_explicit & MASK_FIX_R10000) == 0
       && mips_matching_cpu_name_p (mips_arch_info->name, "r10000"))
     target_flags |= MASK_FIX_R10000;

I assume that won't fire on r12000/r14000/r16000, right?  I know R14K isn't 
affected, but I haven't tried plugging my old R12K module back into the system 
to see what it does.  R16K is likely safe.


> Actually, I meant: I was wondering about the fact that there seems
> to be no online copy of the errata sheet that describes this problem.
> I've only ever seen a description of the workaround.  I've never seen
> a verbatim copy of the errata itself.

I tried seeing whether archive.org had anything old off of the mips.com site, 
but nothing close to the old directory structure seems to exist.  If I new what 
the PDF file name was, it might be possible to track something down on Google 
pertaining to the last publicly released revision.  Bit surprised, too, on why 
NEC doesn't have anything on necel.com.  They produced the actual silicon and 
had a hand in designing it, if I'm not mistaken.  I'd think they would at least 
have a copy if no one else.

-- 
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:[~2009-04-23  6:12 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
2008-11-02 10:00           ` Richard Sandiford
2008-11-03  9:01             ` Kumba [this message]
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=490EBDE2.6010709@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.