REG_N_REFS vs regmove
Jeffrey A Law
Sat Jun 27 10:24:00 GMT 1998
In message < 199806270035.RAA23909@rtl.cygnus.com >you write:
> If a register is eliminated, but REG_N_REFS is still non-zero, then we end
> up allocating a stack slot for it which will never be used. This causes
> us to use more stack space than we should, but is otherwise harmless.
> It would be nice if this was fixed. I have seen this happen before because
> combine didn't update REG_N_REFS. Maybe we could just recompute REG_N_REFS
> before register allocation rather than trying to keep it up-to-date as
> we go along.
I'm thinking more and more that recomputing this info before allocation
is the way to go. We don't have to rerun all of life analysis -- just
walk over the RTL chain counting uses/sets. I would speculate that
we could even remove the code which computes this data in flow.
One thing I found particularly interesting while playing with this is
sometimes the usage counts *increase* (particularly on the x86). So
in the case where they increased from 2 to a higher value we have
the potential for bad things to happen during register allocation.
Recomputing REG_N_REFS and REG_N_SETS showed about a 3.5% improvement
in specfp92 on my x86.
It may also be interesting to see how accurate REG_LIVE_LENGTH is and
whether or not fixing it would help global register allocation.
More information about the Gcc-patches