<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 26 Nov 2025 at 03:09, Zoltan Somogyi <<a href="mailto:zoltan.somogyi@runbox.com">zoltan.somogyi@runbox.com</a>> wrote:</div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">> Eliminate mostly-duplicate work in frameopt.m.<br>> <br>> compiler/frameopt.m:<br>>     The key decision in frame optimization is "which basic blocks need<br>>     a stack frame"?<br>> <br>>     One aspect of this decision is that if a block needs a frame,<br>>     then all successors of that block will get a frame. We therefore<br>>     unconditionally propagate the need for a frame forwards.<br>> <br>>     Another aspect is that if all the successors of a block need a frame,<br>>     then it is better for that block to allocate a frame than for<br>>     all its successors to do so, since this saves space, and does not<br>>     cost any time. We therefore *conditionally* propagate the need<br>>     for a frame backwards.<br>> <br>>     This diff speeds up conditional propagation to predecessors<br>>     by processing each predecessor just once, which reduces the complexity<br>>     of the algorithm from quadratic to linear. This speeds up the compilation<br>>     of options.m by about 13%.<br><br>Has compilation of options.m always had these performance problems or have some<br>of the recent changes to that module exposed them?<br><br>>     This change can change the output slightly (because the result of the<br>>     "do all successors of this predicate need a frame" test can change<br>>     as we learn more about frames), but it seems that in practice, this<br>>     happens only very rarely, and even then its impact on the performance<br>>     of the generate code is negligible.<br><br>s/generate/generated/<br><br>>     The code doing propagation to successors already had a mechanism<br>>     to handle each block just once. Speed up this mechanism also by<br>>     switching the "have we done this block already" test from using<br>>     plain sets (O(N) lookup) to using set_tree234s (O(log(N)) lookup).<br>> <br>>     Also improve some minor aspects of programming style.<br>> <br><br>That looks fine otherwise.<br><br>Julien.<br></div></div></div>