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.
