[Bug target/31110] Problem while compiling gcc for mn10300-elf

["nickc at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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