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