From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108376 invoked by alias); 19 Aug 2019 13:14:26 -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 108357 invoked by uid 89); 19 Aug 2019 13:14:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= 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; Mon, 19 Aug 2019 13:14:24 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 77B36C05AA58 for ; Mon, 19 Aug 2019 13:14:23 +0000 (UTC) Received: from [10.10.122.4] (ovpn-122-4.rdu2.redhat.com [10.10.122.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3589259140 for ; Mon, 19 Aug 2019 13:14:23 +0000 (UTC) Subject: Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra] To: gcc@gcc.gnu.org References: <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> <5693be1f-4351-94ab-9096-f6e4f9f875c1@redhat.com> <20190819073553.pi644qzyokxmynr2@jocasta.intra> From: Vladimir Makarov Message-ID: <16f173b7-d835-48f9-aaed-d5d38d4748ca@redhat.com> Date: Mon, 19 Aug 2019 13:14: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: <20190819073553.pi644qzyokxmynr2@jocasta.intra> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00135.txt.bz2 On 2019-08-19 3:35 a.m., John Darrington wrote: > On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote: > > > 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. > > What I've done is this: > > (define_predicate "my_special_predicate" > (match_operand 0 "memory_operand") > { > debug_rtx (op); > gcc_assert (MEM_P (op)); > op = XEXP (op, 0); > if (GET_CODE (op) == PLUS) > op = XEXP (op, 0); > > if (lra_in_progress) > { > fprintf (stderr, "%s:%d\n", __FILE__, __LINE__); > return REG_P (op) && REGNO (op) >= FIRST_PSEUDO_REGISTER && reg_renumber[REGNO(op)] < 0; > } > > > if (REG_P (op)) > { > int regno = REGNO (op); > return (regno == 10); // register is the stack pointer > } > > return true; > }) > > (and many variations) Unfortunately, any moderately complicated input > still results in a (mem (reg) ) insn repeatedly entering the > lra_in_progress case and returning false, and eventually terminating with > > "internal compiler error: maximum number of generated reload insns per insn achieved (90)" > > > Any other ideas?   As I remember there were a few other ideas from Richard Biener and Segher Boessenkool.  I also proposed to add a new address register which will be always a fixed stack memory slot at the end. Unfortunately I am not familiar with the target and the port to say in details how to do it.  But I think it is worth to try.