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:
  > It looks like a reasonable patch to fix the code generation bug.
  > 
  > + 		    if (REG_N_REFS (sregno) <= 2)
  > + 		      REG_N_REFS (dregno) = 3;
  > 
  > I noticed one typo.  This should be dregno in both places.
Thanks.

  > We would of course get better code if REG_N_REFS was exactly correct,
  > but I don't think that should be a requirement to fix the code generation
  > bug.
Right.  The patch I sent is sufficient to fix the bug.

I brought up the idea of fixing the reference counts primarily because
it would fix this bug and has the potential to improve register allocation.  

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

Another case is when the reference should be two which would allow
us to replace it with a known equivalence.

The last case is the reference counts are used as the basis for
sorting qtys in local alloc.  Thus more accurate counts may give
us better code.

  > 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 believe that recomputing just before local-alloc is safe.  

I'm not even sure we need the refernce counts at all until local
register allocation.  In which case, computing them in flow is
kind of a waste.

jeff


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