This is the mail archive of the
mailing list for the GCC project.
Re: Help with lra
On 08/09/2016 12:33 AM, shmeel gutl wrote:
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.
On 03-Aug-16 12:10 AM, Vladimir Makarov wrote:
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?
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
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).
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
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.