https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #9 from Peter Bergner <bergner at gcc dot gnu.org> --- (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". 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)) 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.
