So, this is actually only true for natural loops :) In particular: "Consideration of only enter_freq is based on the concept that live Out of the entry or head

So, this is actually only true for natural loops :) In particular: "Consideration of only enter_freq is based on the concept that live Out of the entry or header of the Loop is live in and liveout throughout the loop." This is demonstrably false for loops with >1 exit, or multiple latches. IE it assumes that there is a single loop exit and latch that everything goes through. That said, most compilers, however, including GCC, just don't care about loops with these kinds of weird control flow structures, and either duplicate nodes, or just don't consider them loops (https://gcc.gnu.org/onlinedocs/gccint/Loop-representation.html https://gcc.gnu.org/onlinedocs/gccint/Loop-representation.ht...) More interestingly, it's not clear why the patch should make any difference at all, nor is it explained. It just makes an assertion that it is better to do it this way (" This increases the updated memory most and more chances of reducing the spill and fetch and better assignment.") (Expanded on this a bit to make it more clear). When calculating the cost of spills/moves/etc, usually you want to take into account how often a block is executed. This is because you often have multiple places you can put spills/moves/etc to get a register. Multiplying by entry/exit frequencies tells the compiler "If you need a register, it is more expensive to spill something that occurs in a block that happens all the time, than something that occurs in a block that happens infrequently". As an aside, calculating predictions on loops ånd nested-loops statically is non-trivial (it requires estimating the trip count of each loop). In any case, this patch changes the move/spill cost calculation to avoid taking into account the exit frequency of blocks (well, really edges, but let's ignore that) in loops, under the argument that it should be the same as the entry frequency. The problem with that is exactly the last sentence. It shouldn't matter. This change should, in practice, be a no-op, or at best, is a random cost model change. From another perspective, it just divides all the previous frequencies of things in loops by 2 compared to what they were before (assuming the exit frequencies are sane. If they are not, that is a problem to be solved instead of this one). There is no given reason this is a necessarily good thing to do :). Basically, i'm not sure this patch will go in, because it's not clear it's really solving whatever underlying problem exists. I expect someone to come along and tell them to provide better analysis of where exactly it's helping and what the cost numbers are that this is changing "for the better".