This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH/RFC] Avoid invalid subregs during reload, call for testers
On Tue, 5 Dec 2006, Rask Ingemann Lambertsen wrote:
> IMHO you could try modelling the E500 GPRs accordingly: As two 32-bit
> parts. HARD_REGNO_NREGS (GPR+1, SImode) = 1, HARD_REGNO_NREGS (GPR+0,
> DImode) = 4 and HARD_REGNO_NREGS (GPR+0, DFmode) = 2. The tricky part is
I don't think register representations where a DImode value is using
alternate registers (32, 0, 32, 0 bits in successive registers) are really
any better than the present situation, simply a different mess.
> > It turns out there are two different sorts of callers of
> > subreg_regno_offset and subreg_regno. One sort requires the subreg to be
> > representable as a hard reg; for this, the assert is correct. The other
> > sort doesn't, it only wishes to know what range of hard registers may be
> > involved in a given subreg. There are a lot of callers of the latter
> > sort, computing a range of registers.
> Why would the assert not be correct for the latter sort? If using
> start_reg = subreg_regno_offset (innermode, innerreg, outermode, offset);
> end_reg = start_reg + hard_regno_nregs[start_reg][outer_mode] - 1;
> surely your subreg needs to be representable for start_reg and end_reg to be
> correct? I'm also curious as to which callers are of the latter sort.
You shouldn't use hard_regno_nregs with outer_mode here - as I noted a
DImode subreg of a DFmode reg takes one register whereas a normal DImode
reg takes two, and a DFmode subreg of a DImode reg likewise takes two
registers instead of one. But if you compute the number of registers
required correctly for this case (as computed by my function
subreg_get_info), then the range of hard registers involved is fine for
answering questions of the form "What hard registers does this instruction
read from / write to?" or "Do these two operands involve the same
register?" or "What hard registers does this function need to save?".
My belief is that most cases computing ranges like that do not need
representability; (subreg:DI (reg:DF)) and (subreg:DF (reg:DI)) are OK for
them. Whereas cases replacing a subreg by a hard reg such as alter_subreg
do need representability.
Your reload changes can of course be reviewed independently of the assert
of representability, and I hope they will be.
Joseph S. Myers