Fix multi-reg regno_reg_rtx entry

Richard Sandiford rdsandiford@googlemail.com
Sun Jan 29 19:31:00 GMT 2012


Eric Botcazou <ebotcazou@adacore.com> writes:
>> [ BTw, I think the MIPS comment is wrong.  HARD_REGNO_NREGS (fpreg, SFmode)
>>   is (now) 1, even when using paired FPRs.  And the suggestion doesn't
>>   seem at all ideal to me.  OK to remove? ]
>
> You're the MIPS maintainer, so it's up to you.

OK, I'll remove it.

>> A simple fix, which I've used below, is to make sure that the previous
>> mode requires only one register.  We could drop the new assert if we want
>> to be even more conservative at this stage.
>
> That doesn't seem decisively better to me.  Why not use REGNO_REG_CLASS, i.e. 
> copy the mode only if we stay within the same class?

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.

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.

> Btw, could you fix the comment about regno_reg_rtx in emit-rtl.c/function.h?
> It talks about pseudo-registers while we are talking about hard registers.

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.  */

Richard



More information about the Gcc-patches mailing list