From: Richard Sandiford <richard@codesourcery.com>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, David Ung <davidu@mips.com>
Subject: Re: PATCH: MIPS 74K load/store scheduling tweak (take 2)
Date: Sat, 04 Aug 2007 07:35:00 -0000 [thread overview]
Message-ID: <87d4y3da61.fsf@firetop.home> (raw)
In-Reply-To: <46B3C4C0.8030606@codesourcery.com> (Sandra Loosemore's message of "Fri\, 03 Aug 2007 20\:13\:52 -0400")
Sandra Loosemore <sandra@codesourcery.com> writes:
> + /* Conditionally swap the instructions at POS1 and POS2 in ready queue
> + READY, also adjusting the priority of the instruction formerly at
> + POS1 when we do so. */
> +
> + static void
> + mips_maybe_swap_ready (rtx *ready, int pos1, int pos2)
> + {
> + if (pos1 < pos2
> + && INSN_PRIORITY (ready[pos1]) + 4 >= INSN_PRIORITY (ready[pos2]))
> + {
> + rtx temp;
> + INSN_PRIORITY (ready[pos1]) = INSN_PRIORITY (ready[pos2]);
> + temp = ready[pos1];
> + ready[pos1] = ready[pos2];
> + ready[pos2] = temp;
> + }
> + }
To be a general function rather than a 74k function, the magic value
4 should be a parameter too. The comment seems a bit vague: how about
"Make sure the instruction at POS1 in ready queue READY is ahead of
the instruction at POS2, but only if its priority is no less than
LIMIT units of the other instruction's priority. Assume that
only one of the instructions may issue this cycle." Copy-edit
as necessary.
It isn't obvious without the last bit why you're only swapping,
rather than inserting POS1 directly ahead of POS2. With the
comment there, you can remove:
+ /* At this point the ready queue may no longer be sorted, but that's
+ OK since 74k can't schedule concurrent load/store on the same
+ cycle. */
I'm uncertain whether setting INSN_PRIORITY is really the
right thing to do here. David, why isn't the sorting done by
mips_sched_reorder enough?
Looks good otherwise, thanks.
Richard
next prev parent reply other threads:[~2007-08-04 7:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-04 0:13 Sandra Loosemore
2007-08-04 7:35 ` Richard Sandiford [this message]
2007-08-06 16:21 ` David Ung
2007-08-06 16:40 ` Richard Sandiford
2007-08-06 17:19 ` David Ung
2007-08-06 17:53 ` Richard Sandiford
2007-08-07 10:43 ` David Ung
2007-08-10 15:17 ` Sandra Loosemore
2007-08-10 15:22 ` Richard Sandiford
2007-08-10 16:37 ` Sandra Loosemore
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=87d4y3da61.fsf@firetop.home \
--to=richard@codesourcery.com \
--cc=davidu@mips.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=sandra@codesourcery.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).