[llvm-dev] LLVM is getting faster, April edition
Eric Christopher via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 12 08:15:25 PDT 2017
Thanks Michael. These reports are great for both me personally and the llvm
community. It's very appreciated.
On Tue, Apr 11, 2017, 7:49 PM Mikhail Zolotukhin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> It's been a while since I sent the last compile time report , where it
> was shown that LLVM was getting slower over time. But now I'm happy to
> bring some good news: finally, LLVM is getting faster, not slower :)
> *** Current status ***
> Many areas of LLVM have been examined and improved since then:
> InstCombine, SCEV, APInt implementation, and that resulted in almost 10%
> improvement compared to January compiler. I remeasured compile time data
> for CTMark tests and annotated the biggest changes, the graphs for Os and
> O0-g are attached below. Thick black line represents geomean, colored thin
> lines represent individual tests. The data is normalized on the first
> revision in the range (which is ~Jun, 2015).
> *** Future work ***
> There are still plenty of opportunities to make LLVM faster. Here is a
> list of some ideas that can further help compile-time:
> - KnownBits Cache. InstCombine and other passes use known bits, which
> often happens to be pretty expensive. Hal posted a patch  that
> implements a cache for known bits, but there are still some issues to fix
> - SCEV. Some parts of SCEV still need to be improved. For
> instance, createAddRecFromPHI function seems to be very inefficient: it can
> perform many expensive traversals over entire function/loop nest, and most
> of them are probably redundant.
> - Forming LCSSA. PR31851 reports that the current implementation of LCSSA
> forming can be expensive. A WIP patch  should address the problem, but
> probably there are more to be improved here.
> - InstCombine vs InstSimplify. Currently we run InstCombine 6 times in our
> O3 pipeline. Probably, we don't need full InstCombine all 6 times, and some
> of its invocations can be replaced with a cheaper clean-up pass.
> - Unnecessary pass dependencies. There are cases in which computing pass
> dependencies is much more expensive than running the pass itself
> (especially at O0). It might make sense to find such passes and try
> replacing their dependencies with lazy computations of required analyses
> (see e.g. ).
> - libcxx. r249742 split a bunch of headers and resulted in noticeable
> compile time slowdowns. While the change itself seems to be necessary, it
> would be nice to find a way to mitigate the induced slowdowns.
> Of course, the list is far from complete, so if you happen to know other
> problematic areas, please let me know. Some of these ideas are already
> worked on, but there is always a room for volunteers here! So, if you'd
> like to work on LLVM compile time, please, let me know and let's join our
> Thanks for your time,
>  http://lists.llvm.org/pipermail/llvm-dev/2017-January/109188.html
>  https://reviews.llvm.org/D31239
>  https://reviews.llvm.org/D31843
>  https://reviews.llvm.org/D31302
> CTMark -Os:
> CTMark -O0-g:
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev