This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
On Wed, 2007-02-28 at 14:23 +0100, Bernd Schmidt wrote:
> Richard Sandiford wrote:
>
> > In the code guarded by double_reg_address_ok, reload is trying to create
> > a valid offsetable base+index address. Given the above, I think the
> > *_REG_CLASS group of macros -- the "how do I make this address valid?"
> > macros -- ought to be directly telling reload what class of index
> > register is allowed in such an address. And the backend should answer
> > NO_REGS if it doesn't allow any register to be used like that,
> > much as EXTRA_CONSTRAINT would return NO_REGS for register classes
> > that aren't available with the current command-line options.
> > An obvious way do to this would be add an "offsetable_p" argument to
> > MODE_INDEX_REG_CLASS and mode_reg_class (i.e. the addresses.h function
> > in my patch that wraps the target macros).
> >
> > This approach seems far cleaner to me. The current code, and the
> > code after your patch, is jumping through hoops trying to guess what
> > constitutes an offsetable base+index address, and in which contexts
> > such an address is valid. But this is information that the backend knows
> > a priori. I think adding an "offsetable_p" argument to MODE_INDEX_REG_CLASS
> > would be:
>
> I have to say I agree with Richard. Jeff's patch is certainly good as
> far as it goes, but to make the target's addressing mode description
> entirely consistent we'd still need MODE_INDEX_REG_CLASS (although it
> may well be that it makes no real difference at this point). Once we do
> that, it seems that double_reg_address_ok could be eliminated in favour
> of directly using that target macro.
I respectively disagree. For every mode in which indexing is valid on
the coldfire, the same set of index registers is valid. INDEX_REG_CLASS
should be a constant set of registers in this case and G_I_L_A should
simply reject indexing in modes where it is not valid. It's simple and
straightforward and does not require introduction mode dependent index
register classes.
*IF* there was a target where the set of index registers changed based
on the mode, then the mode dependent index register class macro would
make sense. BUt that's not the case here because the invalid indexing
should be rejected by G_I_L_A before we need to worry about the index
register being used.
I'll repeat, the description is consistent and we do not need mode
dependent indexing register descriptions. It's unnecessary and
uselessly complicates things.
Note that double_reg_address_ok is effectively just an optimization so
that reload doesn't have to call into G_I_L_A every time it wants to
determine the best way to reload an out of range stack slot address.
Jeff
- References:
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro
- Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro