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