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.

Reply via email to