From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-a1p-077437.sys.comcast.net (resqmta-a1p-077437.sys.comcast.net [IPv6:2001:558:fd01:2bb4::8]) by sourceware.org (Postfix) with ESMTPS id E607E3858D20 for ; Thu, 12 Jan 2023 01:17:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E607E3858D20 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-a1p-077246.sys.comcast.net ([96.103.145.237]) by resqmta-a1p-077437.sys.comcast.net with ESMTP id FlWOpVcRBtfmtFmDspShv4; Thu, 12 Jan 2023 01:17:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1673486260; bh=sUMrD2wJ2mhbUa/cj516SJedPwhIDRoKRInwZofBVMA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=h6G5Mgn3s3GLbNt6cLztDDmi8ntcBBkrQTZE4sTuXqc+JQLyeB7p+y+ogbZGTiNJS nSQcgMdZiHbl6CGNdKdPNIvbRtkpeBKr9tdoQj8/ayDlVOe8vQuUQFh6kQdymOszwW 7TNlvCEwwq5rb05BOnDs2MXRMYEFklq9h4VNN/zqh5RbS4nRF4H9pckvkm5Bbmf/AU lT1R9AY9vJL4wUygFClwCq0AmxJPfWQdy47T9nRnsZczV53v3hEGwy2oGkZcvm3hbP Hl4OJi1FLtzdU6+NWdPJLlCVnOK91z4vW/DveF81Wawpt28NbsPC4E4eNbleYMXVVD /zBVUMeFGmGIA== Received: from smtpclient.apple ([73.60.223.101]) by resomta-a1p-077246.sys.comcast.net with ESMTPSA id FmDmpgFRO00CiFmDnpeTex; Thu, 12 Jan 2023 01:17:38 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvhedrleehgdeffecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogetfedtuddqtdduucdludehmdenucfjughrpegtggfuhfgjffevgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheprfgruhhlucfmohhnihhnghcuoehprghulhhkohhnihhnghestghomhgtrghsthdrnhgvtheqnecuggftrfgrthhtvghrnhepveekveelffeliefgiedufeehgeejtdfhgedujeehueekiedtgfetffevgffggfdvnecukfhppeejfedriedtrddvvdefrddutddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepshhmthhptghlihgvnhhtrdgrphhplhgvpdhinhgvthepjeefrdeitddrvddvfedruddtuddpmhgrihhlfhhrohhmpehprghulhhkohhnihhnghestghomhgtrghsthdrnhgvthdpnhgspghrtghpthhtohepfedprhgtphhtthhopehprghulhhkohhnihhnghestghomhgtrghsthdrnhgvthdprhgtphhtthhopehsvghghhgvrheskhgvrhhnvghlrdgtrhgrshhhihhnghdrohhrghdprhgtphhtthhopehgtggtsehgtggtrdhgnhhurdhorhhg X-Xfinity-VMeta: sc=-85.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: LRA produces RTL not meeting constraint From: Paul Koning In-Reply-To: <9752D10A-310F-4015-ABA2-48638E9294E3@comcast.net> Date: Wed, 11 Jan 2023 20:17:34 -0500 Cc: Segher Boessenkool , GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <38B62B43-951F-4415-8D4E-1E804A7CA93A@comcast.net> References: <30F1C49F-FD69-4489-B132-61E94AF9A005@comcast.net> <20230111195241.GY25951@gate.crashing.org> <9752D10A-310F-4015-ABA2-48638E9294E3@comcast.net> To: Paul Koning 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: > On Jan 11, 2023, at 7:38 PM, Paul Koning via Gcc = wrote: >=20 >=20 >=20 >> 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:". >=20 > 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 >=20 > 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? >=20 > 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. It occurs to me there's a strange transformation LRA made that I don't = understand, which is the cause of the trouble. Input: (insn 49 48 53 5 (set (reg/f:HI 136) (plus:HI (reg/f:HI 5 r5) (const_int -8 [0xfffffffffffffff8]))) "_mulvdi3.i":38:4 68 = {addhi3} (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5) (const_int -8 [0xfffffffffffffff8])) (nil))) (insn 53 49 50 5 (set (reg/f:HI 137) (symbol_ref:HI ("__muldi3") [flags 0x41] )) "_mulvdi3.i":38:4 25 {movhi} (expr_list:REG_EQUIV (symbol_ref:HI ("__muldi3") [flags 0x41] = ) (nil))) and the IRA "disposition" says it assigned R5 for R136, which is what = should happen given that operand 1 (in the plus:HI) is R5 and the = constraint says that operands 0 and 1 should match. However, Reload shows that it is given: (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136]) (plus:HI (reg/f:HI 6 sp) (const_int 40 [0x28]))) "_mulvdi3.i":38:4 68 {addhi3} (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5) (const_int -8 [0xfffffffffffffff8])) (nil))) In other words, R136 was replaced by R5 as expected -- but at the same = time, the source operands were replaced by something entirely different. = It is a misguided attempt to eliminate the frame pointer? R5 can be = the frame pointer, if it is needed for that purpose. And replacing an = FP reference by an SP reference is reasonable enough, but such a = substitution has to verify that the constraints are still satisfied. Is = that something the target code has to provide? I'm not aware of it. paul