This is the mail archive of the mailing 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]

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
> 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

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