From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-h1p-028590.sys.comcast.net (resqmta-h1p-028590.sys.comcast.net [IPv6:2001:558:fd02:2446::8]) by sourceware.org (Postfix) with ESMTPS id 0153F3858D28 for ; Thu, 12 Jan 2023 00:38:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0153F3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=comcast.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=comcast.net Received: from resomta-h1p-028517.sys.comcast.net ([96.102.179.206]) by resqmta-h1p-028590.sys.comcast.net with ESMTP id FkgbpeNnf3JIzFlcFpNclR; Thu, 12 Jan 2023 00:38:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1673483927; bh=CW35PEcsVw8GswRQf6SWL7jnSzaCB7ppb6UDpXFtR3I=; h=Received:Received:From:Message-Id:Content-Type:Mime-Version: Subject:Date:To:Xfinity-Spam-Result; b=NFAMVtAU7cm1gTBt+UccmiwUqhOJHbnip0vzCLiJwb5TP/AxJQF9O5B64frh3gpz5 c5leUOdyxQn0tEMhSlwHVY1VmghxwM8vVtUo1nF7k9ZkloeHqd8KBxgaq/bjVUqa3i bd2w3Rr1ilFhNkOv7fmxVOAnzFqPsuUHv/N0b3znym2crxGoX8H4gb3h2U/wmug0va o42SZA/UL4uloMF+n+uKskDf6ZLudpSBaO2AOIG+OKZwJVlb5a4Mbqa2HTLRCkeUEe fstWZPzG5R8CtxDWzdnEsVi1wf+QOkpy2FffQyMRcL5uAvhBUELKqOxVJ6r8w5LH5J 0kW0eTEoWRPww== Received: from smtpclient.apple ([73.60.223.101]) by resomta-h1p-028517.sys.comcast.net with ESMTPSA id FlcCp4uvurT1TFlcDpmCjN; Thu, 12 Jan 2023 00:38:47 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvhedrleehgddvhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhkfgtggfuffgjvefvfhfosehmtdhmrehhtddvnecuhfhrohhmpefrrghulhcumfhonhhinhhguceophgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeduvefghfefgfeiffetgfduudeivdeutdevvedulefhveekvdegjedtgeegjefhveenucfkphepjeefrdeitddrvddvfedruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehsmhhtphgtlhhivghnthdrrghpphhlvgdpihhnvghtpeejfedriedtrddvvdefrddutddupdhmrghilhhfrhhomhepphgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtpdhnsggprhgtphhtthhopedvpdhrtghpthhtohepshgvghhhvghrsehkvghrnhgvlhdrtghrrghshhhinhhgrdhorhhgpdhrtghpthhtohepghgttgesghgttgdrghhnuhdrohhrgh X-Xfinity-VMeta: sc=-100.00;st=legit From: Paul Koning Message-Id: <9752D10A-310F-4015-ABA2-48638E9294E3@comcast.net> Content-Type: multipart/mixed; boundary="Apple-Mail=_F421871B-E14B-42F9-B68B-8C908B05E38E" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: LRA produces RTL not meeting constraint Date: Wed, 11 Jan 2023 19:38:44 -0500 In-Reply-To: <20230111195241.GY25951@gate.crashing.org> Cc: GCC Development To: Segher Boessenkool References: <30F1C49F-FD69-4489-B132-61E94AF9A005@comcast.net> <20230111195241.GY25951@gate.crashing.org> X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --Apple-Mail=_F421871B-E14B-42F9-B68B-8C908B05E38E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 11, 2023, at 2:52 PM, Segher Boessenkool = wrote: >=20 > Hi Paul, >=20 > On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote: >> In pdp11.md I have: >>=20 >> (define_insn_and_split "addhi3" >> [(set (match_operand:HI 0 "nonimmediate_operand" "=3DrR,rR,Q,Q") >> (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0") >> (match_operand:HI 2 "general_operand" = "rRLM,Qi,rRLM,Qi")))] >> "" >> "#" >> "reload_completed" >> [(parallel [(set (match_dup 0) >> (plus:HI (match_dup 1) (match_dup 2))) >> (clobber (reg:CC CC_REGNUM))])] >> "" >> [(set_attr "length" "2,4,4,6")]) >>=20 >> While compiling libgcc2.c I see this RTL in the .ira dump file: >>=20 >> (insn 49 48 53 5 (set (reg/f:HI 136) >> (plus:HI (reg/f:HI 5 r5) >> (const_int -8 [0xfffffffffffffff8]))) = "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3} >> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5) >> (const_int -8 [0xfffffffffffffff8])) >> (nil))) >=20 > What hard register was assigned by IRA to r136? It shows this in the > .ira dump file, search for "Disposition:". Disposition: 3:r25 l0 mem 40:r26 l0 4 51:r31 l0 mem 47:r35 l0 = mem 42:r45 l0 2 18:r47 l0 mem 38:r52 l0 mem 34:r54 l0 = mem 29:r64 l0 2 21:r80 l0 0 15:r88 l0 0 2:r99 l0 = 0 19:r102 l0 mem 5:r103 l0 mem 31:r110 l0 0 44:r114 l0 = 0 41:r115 l0 mem 46:r116 l0 0 28:r117 l0 mem 33:r118 l0 = 0 20:r119 l0 2 14:r120 l0 2 1:r121 l0 2 0:r122 l0 = mem 9:r123 l0 mem 8:r124 l0 mem 55:r125 l0 0 53:r126 l0 = mem 54:r129 l0 0 52:r135 l0 0 49:r136 l0 5 48:r137 l0 = 4 50:r139 l0 0 45:r145 l0 mem 43:r146 l0 0 39:r147 l0 = 0 36:r148 l0 5 35:r149 l0 4 37:r151 l0 0 32:r157 l0 = mem 30:r158 l0 0 27:r159 l0 0 25:r160 l0 mem 26:r161 l0 = 0 24:r164 l0 0 22:r165 l0 mem 23:r166 l0 0 16:r170 l0 = mem 17:r171 l0 0 11:r175 l0 0 13:r176 l0 2 12:r177 l0 = 2 10:r178 l0 0 6:r179 l0 mem 7:r180 l0 0 4:r184 l0 = 0 so R5, if I read that correctly. Which makes sense given that the input = operand is R5. =20 >=20 >> Then in the .reload dump it appears this way: >>=20 >> (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136]) >> (plus:HI (reg/f:HI 6 sp) >> (const_int 40 [0x28]))) = "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3} >> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5) >> (const_int -8 [0xfffffffffffffff8])) >> (nil))) >>=20 >> which obviously causes an ICE because that RTL doesn't meet the = constraints. >=20 > Before reload it did not have operands[0] and operands[1] the same, > already? No, and given that it's an addhi3 pattern that is fine before reload. = It's reload that has to make them match because the machine instruction = is two operand. >> This happens only when LRA is used. >>=20 >> I also see this in the .reload file, but I don't know what it means: >>=20 >> Choosing alt 1 in insn 49: (0) rR (1) 0 (2) Qi {addhi3} >=20 > It chose alternative 1 in this instruction, which uses constraints rR > for operands[0], a tie to that for operands[1], and Qi for = operands[2]. >=20 >> 1 Non-pseudo reload: reject+=3D2 >> 1 Non input pseudo reload: reject++ >> Cycle danger: overall +=3D LRA_MAX_REJECT >> alt=3D0,overall=3D609,losers=3D1,rld_nregs=3D2 >> alt=3D1: Bad operand -- refuse >> alt=3D2: Bad operand -- refuse >> alt=3D3,overall=3D0,losers=3D0,rld_nregs=3D0 >=20 > This is for the *next* instruction. There is a "Choosing alt" thing > for that right after this. That will be alt 3: 1 and 2 are refused, > 0 costs 609, 3 costs 0. >=20 > Reading the LRA dumps needs some getting used to ;-) Indeed. So does that mean the discussion about insn 48 is the = interesting one? That goes on for a while: Choosing alt 0 in insn 48: (0) =3DrR (1) RN {movhi} 1 Spill Non-pseudo into memory: reject+=3D3 Using memory insn operand 1: reject+=3D3 1 Non input pseudo reload: reject++ alt=3D0,overall=3D13,losers=3D1,rld_nregs=3D0 0 Spill pseudo into memory: reject+=3D3 Using memory insn operand 0: reject+=3D3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=3D2 1 Non input pseudo reload: reject++ alt=3D1,overall=3D22,losers=3D2 -- refuse 0 Spill pseudo into memory: reject+=3D3 Using memory insn operand 0: reject+=3D3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=3D2 1 Non input pseudo reload: reject++ alt=3D2,overall=3D22,losers=3D2 -- refuse 0 Spill pseudo into memory: reject+=3D3 Using memory insn operand 0: reject+=3D3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=3D2 1 Non input pseudo reload: reject++ alt=3D3,overall=3D22,losers=3D2 -- refuse 0 Spill pseudo into memory: reject+=3D3 Using memory insn operand 0: reject+=3D3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=3D2 1 Non input pseudo reload: reject++ alt=3D4,overall=3D22,losers=3D2 -- refuse 0 Spill pseudo into memory: reject+=3D3 Using memory insn operand 0: reject+=3D3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=3D2 1 Non input pseudo reload: reject++ alt=3D5,overall=3D22,losers=3D2 -- refuse 0 Spill pseudo into memory: reject+=3D3 Using memory insn operand 0: reject+=3D3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=3D2 1 Non input pseudo reload: reject++ alt=3D6,overall=3D22,losers=3D2 -- refuse 0 Spill pseudo into memory: reject+=3D3 Using memory insn operand 0: reject+=3D3 0 Non input pseudo reload: reject++ 1 Non-pseudo reload: reject+=3D2 1 Non input pseudo reload: reject++ alt=3D7,overall=3D22,losers=3D2 -- refuse 1 Non-pseudo reload: reject+=3D2 1 Non input pseudo reload: reject++ Cycle danger: overall +=3D LRA_MAX_REJECT alt=3D8,overall=3D609,losers=3D1,rld_nregs=3D1 alt=3D9,overall=3D0,losers=3D0,rld_nregs=3D0 >> Any ideas? I ran into this when trying to make LRA the default for = this target. >=20 > Please show *all* relevant things in the reload dump file? Everything > about insn 49 or any insn added to reload it, for example. I didn't see anything added to 49, but I'm not sure if I would = necessarily recognize it. One observation is that the previous and next = insns numbers are 48 and 53 in the IRA and Reload dumps both. Attached is a .i file produced from the failing compile, with unneeded = parts removed. It's not really tiny but not all that large. It = consistently shows the failure using a pdp11-aout targeted GCC built = from yesterday's code, when using -O2 or -Os and -mlra. It doesn't fail = with -O1 or if -mlra is omitted (defaulting, in the currently committed = code, to old reload). paul --Apple-Mail=_F421871B-E14B-42F9-B68B-8C908B05E38E Content-Disposition: attachment; filename=_mulvdi3.i Content-Type: application/octet-stream; x-unix-mode=0644; name="_mulvdi3.i" Content-Transfer-Encoding: 7bit typedef int SItype __attribute__ ((mode (SI))); typedef unsigned int USItype __attribute__ ((mode (SI))); typedef int DItype __attribute__ ((mode (DI))); typedef unsigned int UDItype __attribute__ ((mode (DI))); extern DItype __mulvdi3 (DItype, DItype); struct DWstruct {SItype high, low;}; typedef union { struct DWstruct s; DItype ll; } DWunion; DItype __mulvdi3 (DItype u, DItype v) { const DWunion uu = {.ll = u}; const DWunion vv = {.ll = v}; if (__builtin_expect (uu.s.high == uu.s.low >> ((4 * 8) - 1), 1)) { if (__builtin_expect (vv.s.high == vv.s.low >> ((4 * 8) - 1), 1)) { return (DItype) uu.s.low * (DItype) vv.s.low; } else { DWunion w0 = {.ll = (UDItype) (USItype) uu.s.low * (UDItype) (USItype) vv.s.low}; DWunion w1 = {.ll = (UDItype) (USItype) uu.s.low * (UDItype) (USItype) vv.s.high}; if (vv.s.high < 0) w1.s.high -= uu.s.low; if (uu.s.low < 0) w1.ll -= vv.ll; w1.ll += (USItype) w0.s.high; if (__builtin_expect (w1.s.high == w1.s.low >> ((4 * 8) - 1), 1)) { w0.s.high = w1.s.low; return w0.ll; } } } else { if (__builtin_expect (vv.s.high == vv.s.low >> ((4 * 8) - 1), 1)) { DWunion w0 = {.ll = (UDItype) (USItype) uu.s.low * (UDItype) (USItype) vv.s.low}; DWunion w1 = {.ll = (UDItype) (USItype) uu.s.high * (UDItype) (USItype) vv.s.low}; if (uu.s.high < 0) w1.s.high -= vv.s.low; if (vv.s.low < 0) w1.ll -= uu.ll; w1.ll += (USItype) w0.s.high; if (__builtin_expect (w1.s.high == w1.s.low >> ((4 * 8) - 1), 1)) { w0.s.high = w1.s.low; return w0.ll; } } else { if (uu.s.high >= 0) { if (vv.s.high >= 0) { if (uu.s.high == 0 && vv.s.high == 0) { const DItype w = (UDItype) (USItype) uu.s.low * (UDItype) (USItype) vv.s.low; if (__builtin_expect (w >= 0, 1)) return w; } } else { if (uu.s.high == 0 && vv.s.high == (SItype) -1) { DWunion ww = {.ll = (UDItype) (USItype) uu.s.low * (UDItype) (USItype) vv.s.low}; ww.s.high -= uu.s.low; if (__builtin_expect (ww.s.high < 0, 1)) return ww.ll; } } } else { if (vv.s.high >= 0) { if (uu.s.high == (SItype) -1 && vv.s.high == 0) { DWunion ww = {.ll = (UDItype) (USItype) uu.s.low * (UDItype) (USItype) vv.s.low}; ww.s.high -= vv.s.low; if (__builtin_expect (ww.s.high < 0, 1)) return ww.ll; } } else { if ((uu.s.high & vv.s.high) == (SItype) -1 && (uu.s.low | vv.s.low) != 0) { DWunion ww = {.ll = (UDItype) (USItype) uu.s.low * (UDItype) (USItype) vv.s.low}; ww.s.high -= uu.s.low; ww.s.high -= vv.s.low; if (__builtin_expect (ww.s.high >= 0, 1)) return ww.ll; } } } } } __builtin_trap (); } --Apple-Mail=_F421871B-E14B-42F9-B68B-8C908B05E38E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_F421871B-E14B-42F9-B68B-8C908B05E38E--