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 Fri, 2007-02-09 at 15:13 +0000, Richard Sandiford wrote:

The ColdFire FPU has no instructions for moving an indexed address into an FP register. This leads to the crucial point: Right. As I've said, this is a subst of the PA (actually, the PA has no way to do an indexed store from an integer register, but that's close enough).

The bug is about addresses generated by find_reloads_address. If double_reg_address_ok is true, find_reloads_address will reload an out-of-range offset into an index register. So let's say we have: And I believe this is the source of your problem. The backend has lied to reload.

double_reg_address_ok is computed by generating some RTL for addresses, then passing them along to G_I_L_A. If G_I_L_A returns true, then reload deems it is free to generate reg+reg addressing modes.

Specifically the code actually generates

(plus (plus (FP) (indexreg)) (const_int 4))

If it's a valid address for any indexreg, then double_reg_address_ok is set to 1 and reload generates reg+reg addressing modes. Stop lying to reload about the legitimacy of that kind of address and these problems ought to go away. You might even look into the idea of rejecting such addresses only for the sake of reload since I think rejecting them in general is likely to lead to a performance issue on the m68k.

jeff

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