<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Hal and others!</div><div class=""><br class=""></div><div class="">This is the second part of the patch, in which we start to use the obtained estimate of complete loop unrolling effect more aggressively.</div><div class=""><br class=""></div><div class="">The current heuristic is following:</div><div class="">- We have three parameters: Threshold (the existing one), MinPercentOfOptimizedInstructions (new), and AbsoluteThreshold(new).</div><div class="">- If a loop is so small, that unrolling it won’t exceed Threshold, we’ll unroll it.</div><div class="">- If a loop is so big, that unrolling it will exceed AbsoluteThreshold, don’t do it in any case.</div><div class="">- If a loop is something in the middle, unroll it if the unrolling would lead to elimination of the specified part of instructions (in percent). As I explained in previous messages, that could happen if some loads become constants, and these constants help inst-simplify (e.g. it’s 0 or 1, and it’s used in add or mul).</div><div class=""><br class=""></div><div class="">The parameters’ values haven’t been tuned yet, though I don’t see any regressions on SPEC2006 with them (x86, O3, PGO, LTO, ref data), and anyway I plan to do some experiments to tune them in future.</div><div class=""><br class=""></div><div class="">I also added InstSimplify passes right after loop-unroller, because we expect this pass to clean up after complete unrolling if we succeeded. This change can be discussed separately though, and if needed we can skip it in this patch.</div><div class=""><br class=""></div><div class="">Does the patch look good?</div><div class=""><br class=""></div><div class=""></div></body></html>