REG_N_REFS vs regmove

Jeffrey A Law
Sat Jun 27 10:24:00 GMT 1998

  In message < >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 mailing list