From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96803 invoked by alias); 4 Aug 2019 19:18:29 -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 96795 invoked by uid 89); 4 Aug 2019 19:18:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=H*F:U*john, solves, imagine, lra 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; Sun, 04 Aug 2019 19:18:24 +0000 Received: from jocasta.intra (localhost [127.0.0.1]) by jocasta.intra (8.15.2/8.15.2/Debian-8) with ESMTPS id x74JIMJK030332 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 4 Aug 2019 21:18:22 +0200 Received: (from john@localhost) by jocasta.intra (8.15.2/8.15.2/Submit) id x74JIMIB030331 for gcc@gcc.gnu.org; Sun, 4 Aug 2019 21:18:22 +0200 Date: Sun, 04 Aug 2019 19:18:00 -0000 From: John Darrington To: gcc@gcc.gnu.org Subject: Indirect memory addresses vs. lra Message-ID: <20190804191822.x4hwnfcyplnto3xc@jocasta.intra> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ppz5aqe3ztnjr5nv" Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00010.txt.bz2 --ppz5aqe3ztnjr5nv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2749 I'm trying to write a back-end for an architecture (s12z - the ISA you can= =20 download from [1]). This arch accepts indirect memory addresses. That is= to=20 say, those of the form (mem (mem (...))) and although my TARGET_LEGITIMATE= _ADDRESS function returns true for such addresses, LRA insists on reloading them out= of=20 existence. For example, when compiling a code fragment: volatile unsigned char *led =3D 0x2F2; *led =3D 1; the ira dump file shows: (insn 7 6 8 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8]) (const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movp= si} (nil)) (insn 8 7 14 2 (set (mem/v:QI (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])= [0 *led_7+0 S1 A8]) (const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi} (nil)) which is a perfectly valid insn, and the most efficient assembler for it is: mov.p #0x2f2, y mov.b #1, [0,y] However the reload dump shows this has been changed to: (insn 7 6 22 2 (set (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8]) (const_int 754 [0x2f2])) "/home/jmd/MemMem/memmem.c":15:27 96 {movp= si} (nil)) (insn 22 7 8 2 (set (reg:PSI 8 x [22]) (mem/f/c:PSI (reg/f:PSI 9 y) [3 led+0 S4 A8])) "/home/jmd/MemMem/me= mmem.c":16:8 96 {movpsi} (nil)) (insn 8 22 14 2 (set (mem/v:QI (reg:PSI 8 x [22]) [0 *led_7+0 S1 A8]) (const_int 1 [0x1])) "/home/jmd/MemMem/memmem.c":16:8 98 {movqi} (nil)) and ends up as: mov.p #0x2f2, y mov.p (0,y) x mov.b #1, (0,x) So this wastes a register (which leads to other issues which I don't want t= o go=20 into in this email). After a lot of debugging I tracked down the part of lra which is doing this= =20 reload to the function process_addr_reg at lra-constraints.c:1378 if (! REG_P (reg)) { if (check_only_p) return true; /* Always reload memory in an address even if the target supports suc= h addresses. */ new_reg =3D lra_create_new_reg_with_unique_value (mode, reg, cl, "add= ress"); before_p =3D true; } Changing this to if (! REG_P (reg)) { if (check_only_p) return true; return false; } solves my immediate problem. However I imagine there was a reason for doin= g=20 this reload, and presumably a better way of avoiding it. Can someone explain the reason for this reload, and how I can best ensure t= hat=20 indirect memory operands are left in the compiled code? [1] https://www.nxp.com/docs/en/reference-manual/S12ZCPU_RM_V1.pdf --=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. --ppz5aqe3ztnjr5nv Content-Type: application/pgp-signature; name="signature.asc" Content-length: 195 -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSHl6JtCFQuqwKFopCKZ3GcLegnswUCXUcvdQAKCRCKZ3GcLegn s+D/AJ9kAKI3C8cF3uVLuYVkzkkmFhpSkACePf+bXAYvh8MxpYSl4f1HLMfPaCM= =u7Kv -----END PGP SIGNATURE----- --ppz5aqe3ztnjr5nv--