Jan Hubicka <hubi...@kam.mff.cuni.cz> writes: >> The final index into (ira_)memory_move_cost is 1 for loads and >> 0 for stores. Thus the combination: >> >> entry_freq * memory_cost[1] + exit_freq * memory_cost[0] >> >> is the cost of loading a register on entry to a loop and >> storing it back on exit from the loop. This is the cost to >> use if the register is successfully allocated within the >> loop but is spilled in the parent loop. Similarly: >> >> entry_freq * memory_cost[0] + exit_freq * memory_cost[1] >> >> is the cost of storing a register on entry to the loop and >> restoring it on exit from the loop. This is the cost to >> use if the register is spilled within the loop but is >> successfully allocated in the parent loop. >> >> The patch adds a helper class for calculating these values and >> mechanically replaces the existing instances. There is no attempt to >> editorialise the choice between using “spill inside” and “spill outside” >> costs. (I think one of them is the wrong way round, but a later patch >> deals with that.) >> >> No functional change intended. >> >> gcc/ >> PR rtl-optimization/98782 >> * ira-int.h (ira_loop_border_costs): New class. >> * ira-color.c (ira_loop_border_costs::ira_loop_border_costs): >> New constructor. >> (calculate_allocno_spill_cost): Use ira_loop_border_costs. >> (color_pass): Likewise. >> (move_spill_restore): Likewise. > > Thanks for working on this. For profile bits, the patch looks good to > me. In general I am trying to move away from the integer frequencies. > It would be more precise to calculate the m_entry_freq and m_exit_freq > as profile_count m_entry_count, m_exit_count > and do conversion only later. > > count->to_frequency method basically scales it to the range 0...BB_FREQ_MAX.
Yeah. If I get time, I'd like to see how easy it would be to move the RAs away from the BB_FREQ_MAX scaling. I agree it's not really precise enough. The problem is that the costs are multiplied by several other things, and there have recently been overflow problems (g:7d02c8bf75980fa2468f). I guess the way to avoid that would be to use sreals, but the problem then is that the costing code (particularly record_reg_classes) is very compile-time sensitive. So it might need a bit of surgery to move over to sreal costs without negatively affecting compile time (and perhaps memory consumption). Of course, RA changes would become much easier if we got rid of old reload. :-) (OK, bit of a cheap shot in this case, but true in general.) Thanks, Richard
