public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <rdsandiford@googlemail.com>
To: Kumba <kumba@gentoo.org>
Cc: gcc-patches@gcc.gnu.org,  mips@gentoo.org
Subject: Re: [PATCH]: GCC Scheduler support for R10000 on MIPS
Date: Sat, 16 Aug 2008 10:10:00 -0000	[thread overview]
Message-ID: <87bpzt5rrs.fsf@firetop.home> (raw)
In-Reply-To: <48A26993.1010605@gentoo.org> (kumba@gentoo.org's message of 	"Wed\, 13 Aug 2008 00\:56\:51 -0400")

Kumba <kumba@gentoo.org> writes:
> gcc/
>      * config/mips/10000.md: Add R10000 scheduler
>      * config/mips/mips.c: Add r10000 params & costs
>      * config/mips/mips.h: Add R10k constant
>      * config/mips/mips.md: Add r10000 params & incl 10000.md
>      * doc/invoke.texi: List r1x000 family

Looks good, thanks.  Minor comment nits:

> +;; Integer add/sub + logic ops, and mt hi/lo can be done by alu1 or alu2.
> +;; Miscellaneous arith goes here too (this is a guess).
> +(define_insn_reservation "r10k_arith" 1
> +  (and (eq_attr "cpu" "r10000")
> +       (eq_attr "type" "arith,mthilo,slt,clz,const,nop,trap,logical"))
> +  "r10k_alu1 | r10k_alu2")

Not sure if this is really a guess.  "arith" is "general ALU stuff
that we haven't needed to split out as separate types".  So if
shifts and conditional moves are really the only non-branching
instructions that require a particular ALU (ALU1), then I think we
can be pretty confident this is right.

> +;; We treat mfhilo differently, because we need to know when
> +;; it's HI and when it's LO.
> +(define_insn_reservation "r10k_mfhi" 1
> +  (and (eq_attr "cpu" "r10000")
> +       (and (eq_attr "type" "mfhilo")
> +            (not (match_operand 1 "lo_operand"))))
> +  "r10k_alu1 | r10k_alu2")
> +
> +(define_insn_reservation "r10k_mflo" 1
> +  (and (eq_attr "cpu" "r10000")
> +       (and (eq_attr "type" "mfhilo")
> +            (match_operand 1 "lo_operand")))
> +  "r10k_alu1 | r10k_alu2")

s/We treat mfhilo differently/We use separate reservations for mfhilo/

> +;; Only ALU2 does int multiplications and divisions.
> +;;
> +;; According to the Vr10000 series user manual,
> +;; integer mult and div insns can be issued one
> +;; cycle earlier if using register Lo.  We model
> +;; this by using the Lo value by default, as it
> +;; is the more common value, and use a bypass
> +;; for the Hi value when needed.
> +;;
> +;; Also of note, There are different latencies
> +;; for MULT/DMULT (Lo 5/Hi 6) and MULTU/DMULTU (Lo 6/Hi 7).
> +;; However, gcc does not have separate types
> +;; for these insns.  Thus to strike a balance,
> +;; we use the Hi latency value for imul
> +;; operations to strike a balance until the
> +;; imul type can be split.

s/to strike a balance until/until/

> +;; Divides also keep ALU2 busy, but this isn't modeled
> +;; here.

Needs clarifying.  Integer divides _are_ modelled as using r10k_alu2.

OK otherwise.  Do you have a copyright assignment on file?

Let me know if you have svn write access.  I'll apply the patch
for you if not.

Richard

  reply	other threads:[~2008-08-16  7:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-01  1:53 Kumba
2008-08-02  4:29 ` Kumba
2008-08-02  9:48 ` Richard Sandiford
2008-08-03  3:37   ` Kumba
2008-08-03  7:20     ` Ralf Wildenhues
2008-08-03 10:40     ` Richard Sandiford
2008-08-04  7:20       ` Kumba
2008-08-04 19:23         ` Richard Sandiford
2008-08-04 19:30           ` contribute.html: compare pre/post patch testresults (was: [PATCH]: GCC Scheduler support for R10000 on MIPS) Ralf Wildenhues
2008-08-06 14:51             ` Ian Lance Taylor
2008-08-05  2:48           ` [PATCH]: GCC Scheduler support for R10000 on MIPS Kumba
2008-08-05 18:29             ` Richard Sandiford
2008-08-06  7:58               ` Kumba
2008-08-07 21:24                 ` Richard Sandiford
2008-08-08  8:46                   ` Kumba
2008-08-09  9:01                     ` Richard Sandiford
2008-08-13  8:53                       ` Kumba
2008-08-16 10:10                         ` Richard Sandiford [this message]
2008-08-18  8:51                           ` Kumba
2008-08-18 17:00                             ` David Daney
2008-08-19  2:59                               ` Kumba
2008-10-06 21:33                             ` Richard Sandiford

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=87bpzt5rrs.fsf@firetop.home \
    --to=rdsandiford@googlemail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kumba@gentoo.org \
    --cc=mips@gentoo.org \
    /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).