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

[Madhur Amilkanthwar via llvm-dev]

I am interested in knowing more.
1. What benchmarks does LLVM community use for compile-time study? I see
CTMark, but is that the only one being analyzed?
2. Is ASM parsing treated as a bottleneck in the flow? It is not the
default in the compilation flow though.
3. Do we have a target here? how fast does LLVM want to be?

On Wed, Apr 12, 2017 at 8:22 AM, 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
>
>


-- 
*Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
mail are of my own and my employer has no take in it. *
Thank You.
Madhur D. Amilkanthwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170412/83571afe/attachment.html>