Jeff Law wrote:
On 11/30/09 14:48, Michael Eager wrote:
Jeff Law wrote:
On 11/30/09 14:17, Michael Eager wrote:
I've run into a situation where assign_hard_reg()
decides that there are no registers available.
That can certainly happen. It's also the case that assign_hard_reg
may decide that memory is cheaper than a register and refuse to
assign a register for certain allocnos.
This
results in a memory reference being substituted for a
pseudo-register. There's no check to see if the modified
instruction is valid, which it isn't.
reload performs this action, not IRA. Reload is allowed to replace
a pseudo with its equivalent memory location, then emit whatever
reloads are necessary to fix up the resulting insn. So what you need
to do is debug the generated reloads for the insn in question.
Often this kind of failure is a predicate, constraint or secondary
reload problem.
Thanks. I did step through reload and it looked
like everything it was doing was OK.
I'll look at reload again and re-check constraints.
Also double check your predicates and look at secondary reload issues.
It's not uncommon to need to define secondary reloads for oddball
cases. If you described more attributes of your target we might be
able to point you at another target with similar attributes and describe
how it handles these situations.
Xilinx MicroBlaze. Not too odd a processor -- RISC, 3-addr.
It was working OK with the IAR register allocator until I
removed some of the branch instruction templates which
should no longer be necessary. AFAIK, this should not have
changed constraints or predicates.
--
Michael Eager ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
