------- Comment #7 from nickc at redhat dot com 2008-03-27 08:26 ------- Subject: Re: Problem while compiling gcc for mn10300-elf
Hi Jeff, >> The CLASS is DATA_OR_EXTENDED_REGS. >> (plus:SI (reg/f:SI 9 sp) >> (const_int 1100 [0x44c])) > Hmm, so why isn't this caught by this code in secondary_reload_class: > > /* We can't directly load sp + const_int into a data register; > we must use an address register as an intermediate. */ > if (class != SP_REGS > && class != ADDRESS_REGS > && class != SP_OR_ADDRESS_REGS > && class != SP_OR_EXTENDED_REGS > && class != ADDRESS_OR_EXTENDED_REGS > && class != SP_OR_ADDRESS_OR_EXTENDED_REGS > && (in == stack_pointer_rtx > || (GET_CODE (in) == PLUS > && (XEXP (in, 0) == stack_pointer_rtx > || XEXP (in, 1) == stack_pointer_rtx)))) > return ADDRESS_REGS; > > > In fact, I'm having trouble seeing why the clause which returns > DATA_REGS/DATA_OR_EXTENDED_REGS exists at all. > > Am I being overly dense today? Nope, when you pointed it out to me I puzzled over it too. The answer is quite simple though, at the point where mn10300_secondary_reload_class is called the value of CLASS is ADDRESS_REGS, which explains why the above fragment of code is not triggered. I guess it makes sense - if you need to perform a reload of a stack pointer manipulation then the obvious first choice of class is the address registers. If that does not work, say because the stack adjustment is too big, then using a data or extended register and performing direct arithmetic on the stack pointer is the way to go. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
