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

Re: egcs-1.1 status



  In message <199808222336.XAA00899@ongaonga.chch.cri.nz>you write:
  > Jeffrey A Law writes:
  > 
  >  > Fixing regparm to work means killing SMALL_REGISTER_CLASSES.  Which
  >  > would be a good thing, but is a huge amount of work.
  > 
  > Kill, kill, kill!  What approach is required to remove this horrid
  > hack?  A rewrite of reload?  I have to define this for the sake of one
  > rare insn that requires a restrictive register class that clashes with
  > incoming function argument registers.
Yup pretty much rewriting reload.  It also bleeds into other optimization
passes like combine, jump, etc.


The specific problem with regparm is that given a series of insns
which load up parameter registers, we can end up clobbering a
previously loaded parameter register while trying to satisfy reloads
for later parameter loads.

Machines which do not define SMALL_REGISTER_CLASSES do not have this
problem since they do not allow any register explicitly mentioned in
the RTL to be used as a reload register.

So, obviously the first thing we need to make this work is a much
more intelligent reload pass.  It would need to track register
lifetimes at each insn so that it could select an appropriate reload
reg (ie one that doesn't have a live value).  Obviously if no regs
are available for reloading, you have to spill whatever value is in
the hard register we want to use as a reload reg.

Note this would allow us to generate more efficient code since spills
would localized (ie you spill the value in the reload reg at the
time when the reload reg is needed instead of spilling all values
which are assigned to the reload reg throughout the function.

This would also allow us to detect cases where an asm causes reload
to totally run out of registers and abort instead of generating bad
code.

It's a lot of work, but I think the long term benefits are large.  I'm
willing to help guide someone else working on this problem, but I don't
have the time to tackle it myself.


jeff


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