From: Vladimir Makarov <vmakarov@redhat.com>
To: John Darrington <john@darrington.wattle.id.au>,
Jeff Law <law@redhat.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
Paul Koning <paulkoning@comcast.net>,
gcc@gcc.gnu.org
Subject: Re: Indirect memory addresses vs. lra
Date: Fri, 09 Aug 2019 17:34:00 -0000 [thread overview]
Message-ID: <70b9bcc9-e12a-78b4-b8cc-a67b7ca3d38d@redhat.com> (raw)
In-Reply-To: <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra>
On 2019-08-09 4:14 a.m., John Darrington wrote:
> On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote:
>
> Yea, it's certainly designed with the more mainstream architectures in
> mind. THe double-indirect case that's being talked about here is well
> out of the mainstream and not a feature of anything LRA has targetted to
> date. So I'm not surprised it's not working.
>
> My suggestion would be to ignore the double-indirect aspect of the
> architecture right now, get the port working, then come back and try to
> make double-indirect addressing modes work.
>
> This sounds like sensible advice. However I wonder if this issue is
> related to the other major outstanding problem I have, viz: the large
> number of test failures which report "Unable to find a register to
> spill" - So far, nobody has been able to explain how to solve that
> issue and even the people who appear to be more knowlegeable have
> expressed suprise that it is even happening at all.
Basically, LRA behaves here as older reload. If an RTL insn needs hard
regs and there are no free regs, LRA/reload put pseudos assigned to hard
regs and living through the insn into memory. So it is very hard to run
into problem "unable to find a register to spill", if the insn needs
less regs provided by architecture. That is why people are surprised.Â
Still it can happens as one RTL insn can be implemented by a few machine
insns. Most frequent case here are GCC asm insns requiring a lot of
input/output/and clobbered regs/operands.
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.
The less regs the architecture has, the 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.
> Even if it should turn out not to be related, the message I've been
> receiving in this thread is lra should not be expected to work for
> non "mainstream" backends. So perhaps there is another, yet to be
> discovered, restriction which prevents my backend from ever working?
>
> On the other hand, given my lack of experience with gcc, it could be
> that lra is working perfectly, and I have simply done something
> incorrectly. But the uncertainty voiced in this thread means that it
> is hard to be sure that I'm not trying to do something which is
> currently unsupported.
LRA/reload is the most machine-dependent machine-independent pass in
GCC. It is connected to machine-dependent code by numerous ways. Big
part of making a new backend is to make LRA/reload and
machine-dependent code communication in the right way.
Sometimes it is hard to decide who is responsible for RA related bugs:
RA or back-end. Sometimes an innocent change in RA solving one problem
for a particular target might results in numerous new bugs for other
targets. Therefore it is very difficult to say will your small change
to permit indirect memory addressing work in general case.
next prev parent reply other threads:[~2019-08-09 17:34 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 [this message]
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=70b9bcc9-e12a-78b4-b8cc-a67b7ca3d38d@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).