> I'm not sure REGNO_REG_CLASS is meaningful here, because many ports define > subclasses of the natural architectural classes. E.g. MIPS has MD0_REG > and MD1_REG for HI and LO (which is which depends on endianness), even > though both are logically the same in terms of architectural class and > register width. Same for things like LEA_REGS, PIC_FN_ADDR_REG, etc. > If we switch to word_mode even when the previous mode has the right > number of registers, we risk breaking ports that define subclasses of > smaller-than-word registers.
Fair enough. > It's not like the mode class is really significant here. If a > floating-point register can store an integer mode, choose_hard_reg_mode > will pick an integer mode instead of a floating-point one. E.g. in the > original testcase, FPRs get DImode rather than DFmode. So if the previous > mode is OK, there doesn't seem any harm in using it, and continuing to use > it seems more conservative at this stage of development than hoping that > word_mode is OK. There doesn't seem to be any harm until this breaks! Clearly anything can happen at a boundary between register classes, but your solution is indeed probably the least disturbing one. I'm not sure about the assertion though: if it happens to trigger, the fix will probably entail far-reaching changes in the back-end, so it's probably safer to delay it until the next stage #1. FWIW, reg_raw_mode contains completely bogus values for the upper FP regs on the 32-bit SPARC (w/ or w/o your patch): all SImode! > OK, how's this: > > /* Indexed by register number, gives an rtx for that register (and only > that register). For pseudo registers, it is the unique rtx for > that pseudo. For hard registers, it is an rtx of the mode specified > by reg_raw_mode. > > FIXME: We could put it into emit_status struct, but gengtype is not > able to deal with length attribute nested in top level structures. */ Perfect, thanks. -- Eric Botcazou
