Indirect memory addresses vs. lra

[Vladimir Makarov]

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.