https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #11 from Surya Kumari Jangala <jskumari at gcc dot gnu.org> --- (In reply to Peter Bergner from comment #9) > (In reply to Surya Kumari Jangala from comment #8) > > However, while computing the save/restore cost, we are considering only the > > memory move cost but not the BB frequency. I think it is important to > > consider the frequency too. > > Yes, you'll need to factor in the BB frequency. Since the save/restore code > will go into (at this point modulo shrink-wrapping later) the prologue and > epilogue, you'll want something like: <prologue/epilogue freq> * 2 * > "ira_memory_move_cost". Thanks for confirming that we have to factor in the BB frequency. > I think the issue here, is that the "frequency" of the entry block isn't > '1', but some larger value. I'm not 100% sure, but maybe you can use: > REG_FREQ_FROM_BB (ENTRY_BLOCK_PTR_FOR_FN (cfun)) This works. It gives the frequency of the entry block. > for the BB frequency of the prologue/epilogue? > > > > We factor in the frequency when we compute the > > savings on removed copies in allocno_copy_cost_saving(). In this routine, we > > multiply the frequency with ira_register_move_cost. So why not factor in the > > frequency for memory move cost? > > allocno_copy_cost_saving() is dealing with an actual copy instruction(s), so > a real instruction in a specific BB, so it knows the frequency of the > copy(ies). The ira_memory_move_cost is more of a HW cost of a generic > load/store and it isn't tied to a specific instruction, so there is no > frequency to scale by, so you'll need to do that manually here.
