From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25059 invoked by alias); 19 Mar 2013 21:23:37 -0000 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 Received: (qmail 22407 invoked by uid 89); 19 Mar 2013 21:23:17 -0000 X-Spam-Sware-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_HI,SPF_NEUTRAL,TW_QE autolearn=ham version=3.3.1 Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 19 Mar 2013 21:23:10 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UI3IC-0007YP-A0 for gcc-patches@gcc.gnu.org; Tue, 19 Mar 2013 16:38:03 -0400 Received: from mail-we0-x232.google.com ([2a00:1450:400c:c03::232]:49378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UI3IC-0007Y7-03 for gcc-patches@gcc.gnu.org; Tue, 19 Mar 2013 16:37:56 -0400 Received: by mail-we0-f178.google.com with SMTP id o45so814555wer.9 for ; Tue, 19 Mar 2013 13:37:54 -0700 (PDT) X-Received: by 10.180.7.133 with SMTP id j5mr1650146wia.15.1363725474520; Tue, 19 Mar 2013 13:37:54 -0700 (PDT) Received: from localhost ([2.26.173.20]) by mx.google.com with ESMTPS id du2sm3019950wib.0.2013.03.19.13.37.52 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 19 Mar 2013 13:37:53 -0700 (PDT) From: Richard Sandiford To: "Moore\, Catherine" Mail-Followup-To: "Moore\, Catherine" ,"gcc-patches\@gcc.gnu.org" , "Rozycki\, Maciej" , rdsandiford@googlemail.com Cc: "gcc-patches\@gcc.gnu.org" , "Rozycki\, Maciej" Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support References: <87y5mfjm4c.fsf@talisman.home> <871ubukhs7.fsf@talisman.default> <87d2vdtv3x.fsf@talisman.default> <871ubhem70.fsf@talisman.default> <878v5jp4xl.fsf@talisman.default> Date: Tue, 19 Mar 2013 21:23:00 -0000 In-Reply-To: (Catherine Moore's message of "Tue, 19 Mar 2013 20:28:28 +0000") Message-ID: <874ng7p1lr.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::232 X-SW-Source: 2013-03/txt/msg00712.txt.bz2 "Moore, Catherine" writes: >> -----Original Message----- >> From: Richard Sandiford [mailto:rdsandiford@googlemail.com] >> Sent: Tuesday, March 19, 2013 3:26 PM >> To: Moore, Catherine >> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej >> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support >> >> "Moore, Catherine" writes: >> >> >> -----Original Message----- >> >> >> From: Richard Sandiford [mailto:rdsandiford@googlemail.com] >> >> >> Sent: Tuesday, March 05, 2013 4:06 PM >> >> >> To: Moore, Catherine >> >> >> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej >> >> >> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support: >> >> >> >> >> >> We have a few internal-only undocumented constraints that aren't >> >> >> used much, so we should be able to move them to the "Y" space >> instead. >> >> >> The patch below does this for "T" and "U". Then we could use "U" >> >> >> for new, longer constraints. >> >> >> >> >> >> >> >> >> U >> >> >> >> >> >> where is: >> >> >> >> >> >> s for signed >> >> >> u for unsigned >> >> >> d for decremented unsigned (-1 ... N) >> >> >> i for incremented unsigned (1 ... N) >> >> >> >> >> >> where is: >> >> >> >> >> >> b for "byte" (*1) >> >> >> h for "halfwords" (*2) >> >> >> w for "words" (*4) >> >> >> d for "doublewords" (*8) -- useful for 64-bit MIPS16 but probably not >> >> >> needed for 32-bit microMIPS >> >> >> >> >> >> and where is the number of bits. and could >> >> >> be replaced with an ad-hoc two-letter combination for special cases. >> >> >> E.g. "Uas9" ("add stack") for ADDISUP. >> >> >> >> >> >> Just a suggestion though. I'm not saying these names are totally >> >> >> intuitive or anything, but they should at least be better than >> >> >> arbitrary >> >> letters. >> >> >> >> >> >> Also, could be two digits if necessary, or we could just >> >> >> use hex >> >> digits. >> >> > >> >> > I extended this proposal a bit by: >> >> > 1. Adding a e for encoded. The constraint will start with >> >> > Ue, when the operand is an encoded value. >> >> > 2. I decided to use two digits for . >> >> > 3. The ad-hoc combination is used for anything else. >> >> >> >> First of all, thanks for coming up with a counter-suggestion. I'm >> >> hopeless at naming things, so I was hoping there would be at least some >> pushback. >> >> >> >> "e" for "encoded" sounds good. I'm less keen on the mixture of >> >> single- and double-digit widths though (single digit for some "Ue"s, >> >> double digits for other "U"s.) I think we should either: >> >> >> >> (a) use the same number of digits for all "U" constraints. That leaves >> >> one character for the "Ue" type, which isn't as mnemonic, but is in >> >> line with what we do elsewhere. >> >> >> >> (b) avoid digits in the "Ue" forms and just have an ad-hoc letter >> combination. >> >> FWIW, as far as this point goes, the patch still has "Uea4". >> >> >> > +/* Return true if X is a legitimate address that conforms to the >> >> requirements >> >> > + for any of the short microMIPS LOAD or STORE instructions except >> LWSP >> >> > + or SWSP. */ >> >> > + >> >> > +bool >> >> > +umips_address_p (rtx x, bool load, enum machine_mode mode) { >> >> > + >> >> > + struct mips_address_info addr; >> >> > + bool ok = mips_classify_address (&addr, x, mode, false) >> >> > + && addr.type == ADDRESS_REG >> >> > + && M16_REG_P (REGNO (addr.reg)) >> >> > + && CONST_INT_P (addr.offset); >> >> > + >> >> > + if (!ok) >> >> > + return false; >> >> > + >> >> > + if (mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2) >> >> > + || mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 1)) >> >> > + return true; >> >> > + >> >> > + if (load && IN_RANGE (INTVAL (addr.offset), -1, 14)) >> >> > + return true; >> >> > + >> >> > + if (!load && IN_RANGE (INTVAL (addr.offset), 0, 15)) >> >> > + return true; >> >> > + >> >> > + return false; >> >> > + >> >> > +} >> >> >> >> No blank lines after "{" and before "}". >> >> >> >> More importantly, what cases are these range tests covering? >> >> Both binutils and qemu seem to think that LW and SW need offsets that >> >> exactly match: >> >> >> >> mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2) >> >> >> > >> > Those range tests are for the LBU16 and SB16 instructions. LBU16 >> > supports offsets from -1 to 14 (encodes -1 as 15) while the SB16 insn >> > supports offsets from 0-15. >> >> They need to use separate constraints in that case. The patch as written >> allows -1 offsets for LW16 too. (In rare cases, offsets like -1 can be used even >> with aligned word loads.) >> >> E.g. we could have: >> >> /* Return true if X is legitimate for accessing values of mode MODE, >> if it is based on a MIPS16 register, and if the offset satisfies >> OFFSET_PREDICATE. */ >> >> bool >> m16_based_address_p (rtx x, enum machine_mode mode, >> insn_operand_predicate_fn predicate) { >> struct mips_address_info addr; >> return (mips_classify_address (&addr, x, mode, false) >> && addr.type == ADDRESS_REG >> && M16_REG_P (REGNO (addr.reg)) >> && offset_predicate (addr.offset)); >> } >> >> Perhaps if there are so many of these, we should define "T???" to be a >> memory constraint in which the base register is an M16_REG and in which >> "???" has the same format as for "U". E.g. "Tuw4" for LW and SW. >> That's just a suggestion though. >> > > I'd just as soon leave them as "Z" constraints, if that's okay with you. Yeah, that's fine. > I do see the need for separate constraints. I'll fix that up. > Adding the new microMIPS memory constraints here would take ZS-ZZ. The > base microMIPS patch used ZC and ZD and ZR has been used. > That leaves ZA, ZB, and ZD to ZQ. Sounds good, thanks. Richard