[Bug target/31110] Problem while compiling gcc for mn10300-elf
nickc at redhat dot com
gcc-bugzilla@gcc.gnu.org
Thu Mar 27 08:27:00 GMT 2008
------- 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
More information about the Gcc-bugs
mailing list