public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vladimir Makarov <vmakarov@redhat.com>
To: John Darrington <john@darrington.wattle.id.au>, gcc@gcc.gnu.org
Subject: Re: Indirect memory addresses vs. lra
Date: Thu, 08 Aug 2019 16:25:00 -0000	[thread overview]
Message-ID: <df260cfa-b749-063d-274b-f48d37450d47@redhat.com> (raw)
In-Reply-To: <20190804191822.x4hwnfcyplnto3xc@jocasta.intra>


On 2019-08-04 3:18 p.m., John Darrington wrote:
> 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?
>
The old reload (reload[1].c) supports such addressing.  As modern 
mainstream architectures have no this kind of addressing, it was not 
implemented in LRA.

I don't think the above simple change will work fully.  For example, you 
need to constrain memory nesting.  The constraints should be described, 
may be some hooks should be implemented (may be not and 
TARGET_LEGITIMATE_ADDRESS will be enough), may be additional address 
anslysis and transformations should be implemented in LRA, etc.  But may 
be implementing this is not hard either.

It is also difficult for me to say is it worth to do.  Removing such 
addressing helps to remove redundant memory reads.  On the other hand, 
its usage can decrease #insns and save registers for better RA and 
utilize hardware on design of which a lot of efforts were spent.

In any case, if somebody implements this, it can be included in LRA.

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

  reply	other threads:[~2019-08-08 16:25 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-04 19:18 John Darrington
2019-08-08 16:25 ` Vladimir Makarov [this message]
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=df260cfa-b749-063d-274b-f48d37450d47@redhat.com \
    --to=vmakarov@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=john@darrington.wattle.id.au \
    /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).