public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Indirect memory addresses vs. lra
@ 2019-08-04 19:18 John Darrington
  2019-08-08 16:25 ` Vladimir Makarov
  0 siblings, 1 reply; 38+ messages in thread
From: John Darrington @ 2019-08-04 19:18 UTC (permalink / raw)
  To: gcc

[-- 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 --]

^ permalink raw reply	[flat|nested] 38+ messages in thread
end of thread, other threads:[~2019-08-20  7:30 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-04 19:18 Indirect memory addresses vs. lra John Darrington
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

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).