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] |
Jeff Law wrote: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.On 11/30/09 14:17, Michael Eager wrote: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.I've run into a situation where assign_hard_reg() decides that there are no registers available.
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.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.
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |