From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id B24D43858C83 for ; Wed, 11 Jan 2023 19:54:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B24D43858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 30BJqfCJ003738; Wed, 11 Jan 2023 13:52:41 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 30BJqfsI003737; Wed, 11 Jan 2023 13:52:41 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 11 Jan 2023 13:52:41 -0600 From: Segher Boessenkool To: Paul Koning Cc: GCC Development Subject: Re: LRA produces RTL not meeting constraint Message-ID: <20230111195241.GY25951@gate.crashing.org> References: <30F1C49F-FD69-4489-B132-61E94AF9A005@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30F1C49F-FD69-4489-B132-61E94AF9A005@comcast.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Paul, On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote: > In pdp11.md I have: > > (define_insn_and_split "addhi3" > [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,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")]) > > While compiling libgcc2.c I see this RTL in the .ira dump file: > > (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))) What hard register was assigned by IRA to r136? It shows this in the .ira dump file, search for "Disposition:". > Then in the .reload dump it appears this way: > > (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))) > > which obviously causes an ICE because that RTL doesn't meet the constraints. Before reload it did not have operands[0] and operands[1] the same, already? > This happens only when LRA is used. > > I also see this in the .reload file, but I don't know what it means: > > Choosing alt 1 in insn 49: (0) rR (1) 0 (2) Qi {addhi3} 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]. > 1 Non-pseudo reload: reject+=2 > 1 Non input pseudo reload: reject++ > Cycle danger: overall += LRA_MAX_REJECT > alt=0,overall=609,losers=1,rld_nregs=2 > alt=1: Bad operand -- refuse > alt=2: Bad operand -- refuse > alt=3,overall=0,losers=0,rld_nregs=0 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. Reading the LRA dumps needs some getting used to ;-) > Any ideas? I ran into this when trying to make LRA the default for this target. Please show *all* relevant things in the reload dump file? Everything about insn 49 or any insn added to reload it, for example. Segher