Re: egcs-1.1 status

[Bernd Schmidt <crux at pool dot informatik dot rwth-aachen dot de>]

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

About a year ago I submitted a patch which tries to do exactly what you are
proposing:
 * track which pseudos live in which hard registers for every insn during
   reload
 * Using this information, compute correctly which hard registers are safe
   to use as spill registers
 * spill single pseudos to free hard registers locally instead of spilling
   all pseudos allocated to a hard register that has been selected as spill
   register.

The patch generated a lot better code on the x86, and I believe it fixed the
regparm problems.  I've asked about its status a few times, but I've never
heard back from anyone, so I can only assume no one ever looked at it.  I'd
still like to work on this, but I need some feedback to tell me whether the
approach is valid or whether it should be done differently.

Bernd