DJ Delorie <[EMAIL PROTECTED]> writes: > > What reason is there to have scratch_class be something else? > > SECONDARY_RELOAD_CLASS has the option of limiting the reload class. > The mn10300 has a generic SImode reload_in that allows GENERAL_REGS, > but SECONDARY_RELOAD_CLASS specifies a smaller class based on the > registers that need reloading. > > The default hook for secondary_reload uses SECONDARY_RELOAD_CLASS but > assumes it's going to return the same class as the pattern (in which > case, why bother defining it?). Since we're only allowed one reload > pattern per mode, this seems like an artificial limitation.
Well, first I should note that SECONDARY_RELOAD_CLASS is now considered to be the old way of doing things. Have you considered switching to TARGET_SECONDARY_RELOAD? That said, while it makes sense to me that SECONDARY_RELOAD_CLASS and the reload_{in,out} instruction should be in synch--that was one of the flaws of the old scheme, really--I can't think of anything that would go wrong if class is a subset of scratch_class. You should run any patch past Joern, though. Ian