This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with lra




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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]