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

[Jeffrey Law <law at redhat dot com>]

On Wed, 2007-01-17 at 05:36 +0000, Richard Sandiford wrote:

> I disagree that this patch is a hack.  I think the only real liar here
> is INDEX_REG_CLASS, which says that something is a valid index register
> even when GO_IF_LEGITIMATE_ADDRESS forbids it.
But note this is precisely the same situation as we have with the PA and
IMHO "fixing" it in reload is wrong.   The fact that the address is
invalid has absolutely nothing to do with INDEX_REG_CLASS and everything
to do with whether or not we're using FP load/stores.

The PA port's LEGITIMIZE_RELOAD_ADDRESS is only used to optimize the
generated reloads, removing LEGITIMIZE_RELOAD_ADDRESS from the PA port
will merely generate less optimized code.  Reload will grab a scratch
register and reload the out of range address into the scratch and go on
its merry way.  The limited displacement in reg+d addressing on PA1.0
and PA1.1 chips exercised this code extensively before the introduction
of L_R_A (IIRC, the PA was the first port to define L_R_A to deal with
the horrid code we got because of the limited displacements available
on FP loads and stores).



>   I think the situation
> after the patch is self-consistent and the correct approach to take
> (in terms of what addresses are and aren't acceptable).
Umm, I still disagree.   

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

Note that the PA doesn't necessarily use constraints to accept
or reject indexed addressing modes.  IIRC the indexed addressing
modes are separate patterns.  I don't recall offhand why I made
that change, but it could have well been to avoid the kinds of
problems you're running into.

Basically I still think you're approaching this from the wrong
direction.  Either hide this in the backend, or if you want to
fix reload, then introduce whatever capabilities you need to
reload so that G_I_L_A can recognize when the addresses really
are or are not valid.   For the m68k I think you'd need to
introduce the idea of how the address is going to be used.
ie, for a load from memory, what kind of register is the 
target and for a store to memory, what kind of register
is the source (note this is different from the mode of
the operand, which is purely a GCC-ism and not sufficient).
That's a nontrivial problem ;-)  I looked at it about 10 years
ago.





Jeff