Jeffrey Law - Re: [RTL, ColdFire 24/63] Add support for a MODE_INDEX_REG_CLASS macro (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]