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

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

------- Comment #8 from law at redhat dot com  2008-03-27 18:57 -------
Subject: Re:  Problem while compiling gcc for mn10300-elf

nickc at redhat dot com wrote:
> 
> 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.
So, if CLASS is ADDRESS_REGS, the worst possible scenario I can envision 
  would be for IN to have the form

(plus (stack_pointer_rtx) (pseudo))

Where the pseudo did not get a hard register and lives at a large offset 
   within the local stack.  For that case I think this sequence works 
regardless of what kind of scratch register we are given:


(set (reloadreg) (stack_pointer_rtx))          /* sp into addrreg */
(set (scratch) (reloadreg))                    /* sp into scratch */
(set (reloadreg) (plus (reloadreg) (offset)))  /* ADDR of pseudo */
(set (reloadreg) (mem (reloadreg))             /* get pseudo */
(set (reloadreg) (plus (reloadreg) (scratch))  /* sp + pseudo */



So if reload or the backend can generate that sequence, then I think we 
can indeed return GENERAL_REG like your patch suggests.

Jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110