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

Reply via email to