public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: John Darrington <john@darrington.wattle.id.au>
To: gcc@gcc.gnu.org
Subject: Indirect memory addresses vs. lra
Date: Sun, 04 Aug 2019 19:18:00 -0000	[thread overview]
Message-ID: <20190804191822.x4hwnfcyplnto3xc@jocasta.intra> (raw)

[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]


I'm trying to write a back-end for an architecture (s12z - the ISA you can 
download from [1]).  This arch accepts indirect memory addresses.   That is to 
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 
existence.

For example, when compiling a code fragment:

  volatile unsigned char *led = 0x2F2;
  *led = 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 {movpsi}
     (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 {movpsi}
     (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/memmem.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 to go 
into in this email).

After a lot of debugging I tracked down the part of lra which is doing this 
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 such addresses.  */
      new_reg = lra_create_new_reg_with_unique_value (mode, reg, cl, "address");
      before_p = 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 doing 
this reload, and presumably a better way of avoiding it.

Can someone explain the reason for this reload, and how I can best ensure that 
indirect memory operands are left in the compiled code?



[1] https://www.nxp.com/docs/en/reference-manual/S12ZCPU_RM_V1.pdf

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

             reply	other threads:[~2019-08-04 19:18 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-04 19:18 John Darrington [this message]
2019-08-08 16:25 ` Vladimir Makarov
2019-08-08 16:44   ` Paul Koning
2019-08-08 17:21     ` Segher Boessenkool
2019-08-08 17:25       ` Paul Koning
2019-08-08 19:09         ` Segher Boessenkool
2019-08-08 17:30       ` Paul Koning
2019-08-08 19:19         ` Segher Boessenkool
2019-08-08 19:57           ` Jeff Law
2019-08-09  8:14             ` John Darrington
2019-08-09 14:17               ` Segher Boessenkool
2019-08-09 14:23                 ` Paul Koning
2019-08-10  6:10                 ` John Darrington
2019-08-10 16:15                   ` Segher Boessenkool
2019-08-09 16:07               ` Jeff Law
2019-08-09 17:34               ` Vladimir Makarov
2019-08-10  6:06                 ` John Darrington
2019-08-10 16:12                   ` Segher Boessenkool
2019-08-12  6:47                     ` John Darrington
2019-08-12  8:40                       ` Segher Boessenkool
2019-08-12 13:35                   ` Vladimir Makarov
2019-08-15 16:29                   ` Vladimir Makarov
2019-08-15 16:38                     ` Richard Biener
2019-08-15 17:41                       ` John Darrington
2019-08-15 18:30                       ` Vladimir Makarov
2019-08-15 21:22                         ` Segher Boessenkool
2019-08-15 17:36                     ` John Darrington
2019-08-15 18:23                       ` Vladimir Makarov
2019-08-16 11:24                         ` Special Memory Constraint [was Re: Indirect memory addresses vs. lra] John Darrington
2019-08-16 14:50                           ` Vladimir Makarov
2019-08-19  7:36                             ` John Darrington
2019-08-19 13:14                               ` Vladimir Makarov
2019-08-19 15:07                                 ` Segher Boessenkool
2019-08-19 18:06                                   ` John Darrington
2019-08-20  6:56                                     ` Richard Biener
2019-08-20  7:07                                       ` John Darrington
2019-08-20  7:30                                         ` Richard Biener
2019-08-08 18:46     ` Indirect memory addresses vs. lra Vladimir Makarov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190804191822.x4hwnfcyplnto3xc@jocasta.intra \
    --to=john@darrington.wattle.id.au \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).