[llvm-dev] LLVM is getting faster, April edition

[Eric Christopher via llvm-dev]

Thanks Michael. These reports are great for both me personally and the llvm
community. It's very appreciated.

-eric

On Tue, Apr 11, 2017, 7:49 PM Mikhail Zolotukhin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> It's been a while since I sent the last compile time report [1], 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 [2] that
> implements a cache for known bits, but there are still some issues to fix
> there.
> - 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 [3] 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. [4]).
> - 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
> efforts.
>
> Thanks for your time,
> Michael
>
> [1] http://lists.llvm.org/pipermail/llvm-dev/2017-January/109188.html
> [2] https://reviews.llvm.org/D31239
> [3] https://reviews.llvm.org/D31843
> [4] https://reviews.llvm.org/D31302
>
> CTMark -Os:
> CTMark -O0-g:
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170412/05b7445a/attachment-0001.html>