<div dir="ltr">Is it just renaming you need, or general updating?<br>The RewriteUse call there is one that inserts phis, so i'm not sure renaming alone will help.<div><br></div><div><br></div><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 13, 2017 at 2:48 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Apr 13, 2017 at 1:52 PM, Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>> wrote:<br>
> On Tue, Apr 11, 2017 at 7:52 PM, Mikhail Zolotukhin via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> Hi,<br>
>><br>
>> It's been a while since I sent the last compile time report [1], where it<br>
>> was shown that LLVM was getting slower over time. But now I'm happy to bring<br>
>> some good news: finally, LLVM is getting faster, not slower :)<br>
>><br>
><br>
> Thanks a lot for the update, this is very good to hear :)<br>
><br>
>> *** Current status ***<br>
>> Many areas of LLVM have been examined and improved since then: InstCombine,<br>
>> SCEV, APInt implementation, and that resulted in almost 10% improvement<br>
>> compared to January compiler. I remeasured compile time data for CTMark<br>
>> tests and annotated the biggest changes, the graphs for Os and O0-g are<br>
>> attached below. Thick black line represents geomean, colored thin lines<br>
>> represent individual tests. The data is normalized on the first revision in<br>
>> the range (which is ~Jun, 2015).<br>
>><br>
>> *** Future work ***<br>
>> There are still plenty of opportunities to make LLVM faster. Here is a list<br>
>> of some ideas that can further help compile-time:<br>
>><br>
>> - KnownBits Cache. InstCombine and other passes use known bits, which often<br>
>> happens to be pretty expensive. Hal posted a patch [2] that implements a<br>
>> cache for known bits, but there are still some issues to fix there.<br>
>> - SCEV. Some parts of SCEV still need to be improved. For instance,<br>
>> createAddRecFromPHI function seems to be very inefficient: it can perform<br>
>> many expensive traversals over entire function/loop nest, and most of them<br>
>> are probably redundant.<br>
>> - Forming LCSSA. PR31851 reports that the current implementation of LCSSA<br>
>> forming can be expensive. A WIP patch [3] should address the problem, but<br>
>> probably there are more to be improved here.<br>
><br>
> <a href="https://reviews.llvm.org/rL300255" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>rL300255</a> is a first step towards the goal.<br>
> For some large tests, LCSSA is still slow, and that's due to a lot of<br>
> time spent in the updater. I'll try to fix that one next.<br>
><br>
> --<br>
> Davide<br>
<br>
</div></div>To clarify, here's the profiler output<br>
<a href="https://reviews.llvm.org/F3221946" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>F3221946</a><br>
I think there's not much we can do (easily) for `getExitBlocks()` as<br>
we already cache the call for each loop in `fromLCSSAfoInstructions`<br>
but switching to a faster renamer should help. Dan, do you think it's<br>
possible to move your O(def + use) renamer out of PredicateInfo to a<br>
common file and use that here?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
</font></span></blockquote></div><br></div>