This is the mail archive of the gcc-patches@gcc.gnu.org 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, Dec 05, 2006 at 04:45:26PM +0000, Joseph S. Myers wrote:
> 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

   Make that HARD_REGNO_NREGS (GPR+0, DImode) = 3. I'm thinking that a new
macro along the lines of HARD_REGNO_NREGS_WITH_PADDING would make it
possible to get both (subreg:SI (reg:DI) 4) (and subreg:SI (reg:DF) 4)
right.

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

   The problematic subregs would become representable. Additionally, the
register allocator would have another 32 registers to play with. Even if
most instructions would be unable to use them, they'd likely still be better
than stack slots.

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

   Can you describe somehow what subreg_regno_offset() should return when
the offset isn't representable so that the return value is useful for
computing register ranges?

-- 
Rask Ingemann Lambertsen


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