Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro

[Richard Sandiford <richard at codesourcery dot com>]

Jeffrey Law <law@redhat.com> writes:
> On Wed, 2007-01-17 at 05:36 +0000, Richard Sandiford wrote:
>> The wider issue seems to be: should we either
>> 
>>   (a) allow indexed addresses for all modes and use constraints and
>>       secondary reloads to handle the cases where they aren't allowed or
>> 
>>   (b) prevent the use of index registers for modes if the vast majority
>>       of MEMs in those modes are likely to not be index registers.
> Fundamentally the PA and m68k really need to be rejecting indexed
> address modes since those modes are not valid addressing modes
> according to a strict definition of G_I_L_A.  The two ports lie
> about the legitimitacy of such address modes and if they continue
> to do so, then the details of dealing with the lie really belong
> in the backend (until such time as someone fixes reload and 
> G_I_L_A to be general enough to handle the kinds of cases that
> come up on the m68k and PA).

I don't agree.  You seem to be saying that G_I_L_A has to be independent
of the addressed machine_mode, so that if we forbid index registers for
SFmode, we must do it for all modes.  Or, conversely, if we allow
disp(base,index) addresses for QImode, we must do so for SFmode too.

As I've said before, I think ColdFire's G_I_L_A should continue
rejecting indexed addressing modes for SFmode _not_ for correctness,
but for _optimisation_.  We want to optimise SFmode code based
on the assumption that we will be using the FPU to implement it.
We therefore want to expose the lack of indexed addresses early on,
so that the pre-reload optimisers and register allocators can see the
separate address calculations.  Sure, we lose the ability to copy
SFmode values around using GPRs and indexed addresses, but the
trade-off is IMO a good one.

So, _from an optimisation perspective_, I think it is reasonable to
accept indexed addresses for SImode and not for SFmode.  I'm still
not sure whether you disagree with that.

Now G_I_L_A has a mode argument _precisely_ so that the legitimacy of
an address can depend on the mode.  However, G_I_L_A is not the only
backend interface for describing addressing modes; we also have the
BASE_REG_CLASS and INDEX_REG_CLASS macros.  These latter macros are
all that reload looks at when legitimizing addresses, so they must
of course agree with G_I_L_A.

The problem we have at the moment is that, while G_I_L_A and
BASE_REG_CLASS are parameterised on the mode (and other things),
INDEX_REG_CLASS isn't.  So at the moment, it isn't possible for
the *_REG_CLASS macros to fully agree with G_I_L_A.  My patch
is fixing that, and nothing else.

You seem to be approaching this from the attitude that I'm trying to
solve the question of "how do we expose the different FPR vs. GPR
addressing mode restrictions".  That's not what I'm trying to solve in
this patch.  As I see it, the m68k port implements a good optimisation
decision, but only does so on one side of its addressing mode code.
I'm simply trying to get the other side to agree.  The change is
simple, and is IMO better than ripping out the optimisation.

And I honestly believe this patch is a clean-up as far as the
middle-end goes, because we're now using the same interfaces
both base and index registers.

Richard