From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17787 invoked by alias); 16 Aug 2008 07:44:30 -0000 Received: (qmail 17778 invoked by uid 22791); 16 Aug 2008 07:44:30 -0000 X-Spam-Check-By: sourceware.org Received: from ik-out-1112.google.com (HELO ik-out-1112.google.com) (66.249.90.176) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 16 Aug 2008 07:43:42 +0000 Received: by ik-out-1112.google.com with SMTP id b32so1310505ika.0 for ; Sat, 16 Aug 2008 00:43:39 -0700 (PDT) Received: by 10.210.35.5 with SMTP id i5mr4436518ebi.5.1218872619443; Sat, 16 Aug 2008 00:43:39 -0700 (PDT) Received: from localhost ( [79.75.35.114]) by mx.google.com with ESMTPS id i6sm8125441gve.2.2008.08.16.00.43.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 16 Aug 2008 00:43:38 -0700 (PDT) From: Richard Sandiford To: Kumba Mail-Followup-To: Kumba ,gcc-patches@gcc.gnu.org, mips@gentoo.org, rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org, mips@gentoo.org Subject: Re: [PATCH]: GCC Scheduler support for R10000 on MIPS References: <48926C7B.8060607@gentoo.org> <87hca3ycgt.fsf@firetop.home> <489527D7.6030507@gentoo.org> <87k5ey5qmg.fsf@firetop.home> <4896AD65.1030406@gentoo.org> <87r694sirj.fsf@firetop.home> <4897BCB9.9010806@gentoo.org> <87myjrs5v0.fsf@firetop.home> <489935DD.3060707@gentoo.org> <87sktg1rzz.fsf@firetop.home> <489BE3AC.7020908@gentoo.org> <87bq02d1ns.fsf@firetop.home> <48A26993.1010605@gentoo.org> Date: Sat, 16 Aug 2008 10:10:00 -0000 In-Reply-To: <48A26993.1010605@gentoo.org> (kumba@gentoo.org's message of "Wed\, 13 Aug 2008 00\:56\:51 -0400") Message-ID: <87bpzt5rrs.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg01087.txt.bz2 Kumba 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