From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9119 invoked by alias); 19 Aug 2019 18:06:51 -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 9111 invoked by uid 89); 19 Aug 2019 18:06:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.2 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=hacked, our X-HELO: jocasta.intra Received: from de.cellform.com (HELO jocasta.intra) (88.217.224.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Aug 2019 18:06:49 +0000 Received: from jocasta.intra (localhost [127.0.0.1]) by jocasta.intra (8.15.2/8.15.2/Debian-8) with ESMTPS id x7JI6kWQ010070 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Aug 2019 20:06:46 +0200 Received: (from john@localhost) by jocasta.intra (8.15.2/8.15.2/Submit) id x7JI6i2Y010069; Mon, 19 Aug 2019 20:06:44 +0200 Date: Mon, 19 Aug 2019 18:06:00 -0000 From: John Darrington To: Segher Boessenkool Cc: Vladimir Makarov , gcc@gcc.gnu.org Subject: Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra] Message-ID: <20190819180644.wn7s2dxdgjlwvdw7@jocasta.intra> References: <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> <20190819150711.GL31406@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20190819150711.GL31406@gate.crashing.org> User-Agent: NeoMutt/20170113 (1.7.2) X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00144.txt.bz2 On Mon, Aug 19, 2019 at 10:07:11AM -0500, Segher Boessenkool wrote: > ? As I remember there were a few other ideas from Richard Biener and= =20 > Segher Boessenkool.? I also proposed to add a new address register w= hich=20 > will be always a fixed stack memory slot at the end. Unfortunately I= am=20 > not familiar with the target and the port to say in details how to d= o=20 > it.? But I think it is worth to try. =20=20=20=20=20 The m68hc11 port used the fake Z register approach, and I believe it h= ad some special machine pass to get rid of it right before assembler outp= ut. =20=20=20=20=20 (r171302 is when it was removed -- last version was https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dgcc/config/m68hc11/m= 68hc11.c;h=3D1e414102c3f1fed985e4fb8db7954342e965190b;hb=3Dbae8bb65d842d7ff= efe990c1f0ac004491f3c105#l4061 for the machine reorg stuff). =20=20=20=20=20 No idea how well it works... But it's only needed if you are forced to have a frame pointer IIUC? =20=20=20=20=20 =20=20=20=20=20 Segher Most of these suggestions involve adding some sort of virtual registers So I hacked the machine description to add two new registers Z1 and Z2=20 with the same mode as X and Y. Obviously the assembler balks at this. However the compiler still ICEs at the same place as before. So this suggests that our original diagnosis, viz: there are not enough address registers was not accurate, and in fact there is some other problem? J' --=20 Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3=20 fingerprint =3D 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.