From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69924 invoked by alias); 19 Aug 2019 15:07:16 -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 69910 invoked by uid 89); 19 Aug 2019 15:07:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*i:sk:16f173b, H*f:sk:16f173b X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Aug 2019 15:07:14 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x7JF7CVI025064; Mon, 19 Aug 2019 10:07:12 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x7JF7CIw025063; Mon, 19 Aug 2019 10:07:12 -0500 Date: Mon, 19 Aug 2019 15:07:00 -0000 From: Segher Boessenkool To: Vladimir Makarov Cc: gcc@gcc.gnu.org Subject: Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra] Message-ID: <20190819150711.GL31406@gate.crashing.org> References: <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> <16f173b7-d835-48f9-aaed-d5d38d4748ca@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16f173b7-d835-48f9-aaed-d5d38d4748ca@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00141.txt.bz2 On Mon, Aug 19, 2019 at 09:14:22AM -0400, Vladimir Makarov wrote: > 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. The m68hc11 port used the fake Z register approach, and I believe it had some special machine pass to get rid of it right before assembler output. (r171302 is when it was removed -- last version was https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68hc11/m68hc11.c;h=1e414102c3f1fed985e4fb8db7954342e965190b;hb=bae8bb65d842d7ffefe990c1f0ac004491f3c105#l4061 for the machine reorg stuff). No idea how well it works... But it's only needed if you are forced to have a frame pointer IIUC? Segher