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