From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-a1p-077725.sys.comcast.net (resqmta-a1p-077725.sys.comcast.net [IPv6:2001:558:fd01:2bb4::b]) by sourceware.org (Postfix) with ESMTPS id 60C24385843D for ; Thu, 12 Jan 2023 15:07:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 60C24385843D 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-077053.sys.comcast.net ([96.103.145.230]) by resqmta-a1p-077725.sys.comcast.net with ESMTP id FxAepBtnGl5OPFzAppYfyW; Thu, 12 Jan 2023 15:07:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1673536043; bh=m8BslKVZI9mid+fUTDdT3/Jz4XAjBDTW7TT8/P1YjR0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=ApzNYEMfIWgA3Zi22et4viIjk7nyKY8tlGA3ivWMMM1ygetfClUJKXr1WBsJCUJDI ++LZ97xRQ76Z8nFceAVYzO+jqMl7YYZQkTIuUpgHSBXYxigfI8RIjQ6VLvqDgxTLLc hO7cgeP4dL1I3d9qsCVhRjf8rmVuohogM8Lg2Q01JA6mfuQmRVrMVOFPXILidAEOd3 KohtaFmLTkAhvaydRpP+votMReO43ifFSTfW4kFvSkzEjzKaGzSARVIosqS20/SDza spfRcjXnM5i/q6lvOk19wRqpaU1xspfyzpFqV+bussN/Gkl5na+jfiPaPQn+Z1DDBr hmXtN1b/dZGUw== Received: from smtpclient.apple ([73.60.223.101]) by resomta-a1p-077053.sys.comcast.net with ESMTPSA id FzAmpxl07u8JcFzAnpdGIp; Thu, 12 Jan 2023 15:07:23 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvhedrleeigdejvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjffevgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheprfgruhhlucfmohhnihhnghcuoehprghulhhkohhnihhnghestghomhgtrghsthdrnhgvtheqnecuggftrfgrthhtvghrnhepveekveelffeliefgiedufeehgeejtdfhgedujeehueekiedtgfetffevgffggfdvnecukfhppeejfedriedtrddvvdefrddutddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepshhmthhptghlihgvnhhtrdgrphhplhgvpdhinhgvthepjeefrdeitddrvddvfedruddtuddpmhgrihhlfhhrohhmpehprghulhhkohhnihhnghestghomhgtrghsthdrnhgvthdpnhgspghrtghpthhtohepvddprhgtphhtthhopehsvghghhgvrheskhgvrhhnvghlrdgtrhgrshhhihhnghdrohhrghdprhgtphhtthhopehgtggtqdhprghttghhvghssehgtggtrdhgnhhurdhorhhg X-Xfinity-VMeta: sc=-100.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: [PATCH] wwwdocs: Note that old reload is deprecated From: Paul Koning In-Reply-To: <20230112144030.GA25951@gate.crashing.org> Date: Thu, 12 Jan 2023 10:07:20 -0500 Cc: GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230111151520.GU25951@gate.crashing.org> <20230111183251.GV25951@gate.crashing.org> <20230111192850.GX25951@gate.crashing.org> <9D16702E-DC97-432C-A331-593FE242CE4C@comcast.net> <20230112095059.GZ25951@gate.crashing.org> <6A51E423-A983-42F1-95BB-FFB495050FE2@comcast.net> <20230112144030.GA25951@gate.crashing.org> To: Segher Boessenkool 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 12, 2023, at 9:40 AM, Segher Boessenkool = wrote: >=20 > On Thu, Jan 12, 2023 at 09:17:31AM -0500, Paul Koning wrote: >>> On Jan 12, 2023, at 4:50 AM, Segher Boessenkool = wrote: >>> I mean general_operand accepts that sp thing you saw. But your >>> constraints do not? (I don't know your target well, maybe this = isn't >>> true). Things like this should be sorted out by reload, but you get >>> better code (and fewer problems ;-) ) if you make code that fits >>> earlier. The L in LRA means "local": it "just" makes things fit, it >>> does not emphasise optimising your code. >>=20 >> The destination is "nonimmediate_operand" which matches what the = machine actually does. It's like VAX and M68k, instruction operands in = general can be registers, memory references, register indirect or memory = indirect, memory at register with offset, or autoinc/autodec off any = register. >>=20 >> As far as operand type is concerned, SP is certainly a valid operand = for an add operation, that isn't the problem. The problem is that it's = a two operand machine: the first operand of the add instruction is both = source and destination. And LRA assigned the source register to be the = destination register as required, but then after doing so it replaced = the destination (an FP reference) by a different register (SP = reference), violating the constraint after having satisfied it earlier. >=20 > Ah okay. Yes, something does not verify if the instructions are valid > before doing some replacement. Something around ELIMINABLE_REGS it > looks like? Maybe the dump file says more, or maybe the dump file can > be improved. The Reload dump file mentions in a couple of places that it sees r5 (FP) = as eliminable, replaced by r6 (SP). The IRA dump file says nothing. Yes, the ELIMINABLE_REGS macro says FP can be eliminated, which is = correct. In fact, if it weren't for that, it would be wrong for the = register allocator to pick it (R5) as a general register to hold the = result of that addhi3. So the trouble is that the replacement is made = after that register allocation, and given the constraint the allocator = actually needs to generate an additional instruction, a move from SP to = R5 so it can then do the two-operand add the constraint requires. This feels like a bug; should I file a bug report? Or is there = something the target code can do to make this work? I looked through = the internals manual a bit, it doesn't show anything helpful. The = register elimination hooks are rather generic and don't give me any = handle to recognize cases like this one. paul