From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30628 invoked by alias); 16 Aug 2019 14:50:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 29023 invoked by uid 89); 16 Aug 2019 14:50:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=pseudoregister X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Aug 2019 14:50:18 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8E9633090FE8; Fri, 16 Aug 2019 14:50:15 +0000 (UTC) Received: from [10.10.120.77] (ovpn-120-77.rdu2.redhat.com [10.10.120.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id C77C6183C7; Fri, 16 Aug 2019 14:50:14 +0000 (UTC) Subject: Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra] To: John Darrington Cc: gcc@gcc.gnu.org References: <20190808172102.GH31406@gate.crashing.org> <2EEBCFAE-FF25-4664-AA5F-B3299CEA3CB1@comcast.net> <20190808191914.GK31406@gate.crashing.org> <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra> <70b9bcc9-e12a-78b4-b8cc-a67b7ca3d38d@redhat.com> <20190810060553.m6e42sovw7s4xqoa@jocasta.intra> <20190815173559.kbp3uja7jklx74iy@jocasta.intra> <3c6c87ce-a38f-728d-e083-aa066d531790@redhat.com> <20190816112357.ep7fns6skm5emoey@jocasta.intra> From: Vladimir Makarov Message-ID: <5693be1f-4351-94ab-9096-f6e4f9f875c1@redhat.com> Date: Fri, 16 Aug 2019 14:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190816112357.ep7fns6skm5emoey@jocasta.intra> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00122.txt.bz2 On 2019-08-16 7:23 a.m., John Darrington wrote: > On Thu, Aug 15, 2019 at 02:23:45PM -0400, Vladimir Makarov wrote: > > > I tried this solution earlier. But unfortunately it makes things worse. What happens is it libgcc cannot > > even be built -- ICEs occur on a memory from address reg insn such as: > > (insn 117 2981 3697 5 (set (mem/f:PSI (plus:PSI (reg:PSI 1309) > > (const_int 102 [0x66])) [3 fs_129(D)->pc+0 S4 A8]) > > (reg:PSI 1310)) "/home/jmd/Source/GCC2/libgcc/unwind-dw2.c":977:9 96 {movpsi} > > > I see.?? Then for the insn, you could try to create a pattern > "memory,special memory constraint".?? The special memory constraint > should satisfy only spilled pseudo (pseudo with reg_renumber == -1).?? I > believe lra-constraints.c can spill the pseudo and the end you will have > mem[disp1 + r8|r9|sp] = mem[disp1+sp]. > > You mean something like this: > > (define_special_memory_constraint "a" > "My special memory constraint" > (match_operand 0 "my_special_predicate") > ) > > (define_predicate "my_special_predicate" > (match_operand 0 "memory_operand") > { > debug_rtx (op); > if (MEM_P (op)) > { > op = XEXP (op, 0); > if (GET_CODE (op) == PLUS) > { > op = XEXP (op, 0); > if (REG_P (op)) > { > fprintf (stderr, "Reg number is %d\n", REGNO (op)); > if (REGNO (op) >= 0) > return false; > } > } > } > return true; > }) No I meant something like that (define_special_memory_constraint "a" ...) (define_predicate "my_special_predicate" ... { if (lra_in_progress_p) return REG_P (op) && REGNO (op) >= FIRST_PSEUDO_REGISTER && reg_renumber[REGNO(op)] < 0; return true if memory with sp addressing; }) I think LRA spills pseudo-register and it will be memory addressed by sp at the end of LRA. > When I use this I get lots of the following ICEs > > "internal compiler error: maximum number of generated reload insns per insn achieved (90)" > > It seems logical to me that this would happen since the constraint is not going to match any > operand with resolved registers. Thus it will continually reload. > > ... which makes me think I've probably misunderstood what you are saying. > > J' > >