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]

Re: REG_N_REFS vs regmove



  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.

jeff


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