So, this is actually only true for natural loops :)<p>In particular:
&quot;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.&quot;<p>This is demonstrably false for loops with &gt;1 exit, or multiple latches.<p>IE it assumes that there is a single loop exit and latch that everything goes through.<p>That said, most compilers, however, including GCC, just don&#x27;t care about loops with these kinds of weird control flow structures, and either duplicate nodes, or just don&#x27;t consider them loops (<a href="https:&#x2F;&#x2F;gcc.gnu.org&#x2F;onlinedocs&#x2F;gccint&#x2F;Loop-representation.html" rel="nofollow">https:&#x2F;&#x2F;gcc.gnu.org&#x2F;onlinedocs&#x2F;gccint&#x2F;Loop-representation.ht...</a>)<p>More interestingly, it&#x27;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 (&quot;
This increases the updated memory most and more chances of reducing the spill and
fetch and better assignment.&quot;)<p>(Expanded on this a bit to make it more clear).<p>When calculating the cost of spills&#x2F;moves&#x2F;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&#x2F;moves&#x2F;etc to get a register.  Multiplying by entry&#x2F;exit frequencies  tells the compiler &quot;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&quot;.  As an aside, calculating predictions on loops ånd nested-loops statically is non-trivial (it requires estimating the trip count of each loop).<p>In any case, this patch changes the move&#x2F;spill cost calculation to avoid taking into account the exit frequency of blocks (well, really edges, but let&#x27;s ignore that) in loops, under the argument that it should be the same as the entry frequency.<p>The problem with that is exactly the last sentence.
It shouldn&#x27;t matter.
This change should, in practice, be a no-op, or at best, is a random cost model change.<p>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 :).<p>Basically, i&#x27;m not sure this patch will go in, because it&#x27;s not clear it&#x27;s really solving whatever underlying problem exists.<p>I expect someone to come along and tell them to provide better analysis of where exactly it&#x27;s helping and what the cost numbers are that this is changing &quot;for the better&quot;.