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>
Cc: Jeff Law <law@redhat.com>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Paul Koning <paulkoning@comcast.net>,
	gcc@gcc.gnu.org
Subject: Re: Indirect memory addresses vs. lra
Date: Thu, 15 Aug 2019 16:29:00 -0000	[thread overview]
Message-ID: <be60bf0c-c5f4-dff1-267c-d426d0c6c44e@redhat.com> (raw)
In-Reply-To: <20190810060553.m6e42sovw7s4xqoa@jocasta.intra>

On 8/10/19 2:05 AM, John Darrington wrote:
> On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote:
>       
>       If you provide LRA dump for such test (it is better to use
>       -fira-verbose=15 to output full RA info into stderr), I probably could
>       say more.
>
> I've attached such a dump (generated from gcc/testsuite/gcc.c-torture/compile/pr53410-2.c).
>       
>       The less regs the architecture has, thoke easier to run into such error
>       message if something described wrong in the back-end.?? I see your
>       architecture is 16-bit micro-controller with only 8 regs, some of them is
>       specialized.?? So your architecture is really register constrained.
>
> That's not quite correct.  It is a 24-bit micro-controller (the address
> space is 24 bits wide).  There are 2 address registers (plus stack
> pointer and program counter) and there are 8 general purpose data
> registers (of differing sizes).
>       
>
> J'
>
Thank you for providing the sources.  It helped me to understand what is 
going on.  So the test crashes on

/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: In function ‘f1’:
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1: error: unable to find a register to spill
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1: error: this is the insn:
(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
                 (const_int 32 [0x20])) [2  S4 A64])
         (mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8])) "/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c":9:9 95 {*movsi}
      (expr_list:REG_DEAD (reg:PSI 41)
         (expr_list:REG_DEAD (reg/f:PSI 40 [34])
             (nil))))

Your target has only 2 non-fixed addr registers (r8, r9).  One (r9) is defined as a hard reg pointer pointer. Honestly, I never saw a target with such register constraints.

-O0 assumes -fno-omit-frame-pointer.  So in -O0 mode we have only *one* free addr reg for insn which requires *2* of them.  That is why the GCC port crashes on this test.  If you add -fomit-frame-pointer, the test succeeds.

But even if use -fomit-frame-pointer,  it is not guaranteed that hard reg pointer will be substituted by stack pointer.  There are many cases where it is not possible (e.g. in case of alloca usage).

So what can be done, imho.  The simplest solution would be preventing insns with more one memory operand.  The more difficult solution would be permitting two memory one with address pseudo and another one with stack pointer.

I think only after solving this problem, you could think about implementing indirect memory addressing.

  

  parent reply	other threads:[~2019-08-15 16:29 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
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 [this message]
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=be60bf0c-c5f4-dff1-267c-d426d0c6c44e@redhat.com \
    --to=vmakarov@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=john@darrington.wattle.id.au \
    --cc=law@redhat.com \
    --cc=paulkoning@comcast.net \
    --cc=segher@kernel.crashing.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).