On 10-Aug-16 08:41 PM, Vladimir N Makarov wrote:
On 08/09/2016 12:33 AM, shmeel gutl wrote:
On 03-Aug-16 12:10 AM, Vladimir Makarov wrote:
On 08/02/2016 04:41 PM, shmeel gutl wrote:
I am trying to enable lra for a propriety backend. I ran into one
problem that I can't solve. In lra-constraints.c:split_reg
lra_create_new_reg can be called with a hard code rclass of
NO_REGS. It then queues a move instruction of the type
set TYPE:new_reg TYPE:old_reg
But the NO_REGS rclass stops new_reg from matching a register
constraint and forces a reload. But the reload will have the same
problem. This recurses until the recursion limit is hit.
What is my backend missing that will allow a register assignment to
new_reg?
NO_REGS in this case means memory and the generated RTL move insn
finally should be a target load or store insn. It is hard to say
w/o looking at the code but, probably, your move insn descriptions
do not have memory constraints (or these constraints are quite
specific).
Currently our memory constraints only match memory operands. I assume
that you are suggesting that pseudo registers should match memory
constraints. Is this true only for lra, or, would reload also benefit
from such a change? Would other passes gain by such a change? Is any
extra support needed in patterns or hooks?
Move insn descriptions are quit specific. When you make a port it is
better to have only one move insn for given mode (although there are
some tricks to avoid this). Therefore move insns have a lot of
alternatives. That is what I meant.
As for memory constraint you should not to return true for a pseudo.
Reload/LRA can figure out how to match a spilled pseudo with memory
(but this constraint should be define_memory_constraint, i saw
mistakes when people used different forms of constraints for memory
and had problems).
Again it is hard to say something definite w/o seeing the code what is
the actual problem.
You hit it on the head with define_memory_constraint. Reload didn't seem
to need it but LRA does.
Thank you,
Shmeel
