<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="">Hi Madhur,<br class=""><div><blockquote type="cite" class=""><div class="">On Apr 11, 2017, at 10:25 PM, Madhur Amilkanthwar <<a href="mailto:madhur13490@gmail.com" class="">madhur13490@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I am interested in knowing more.<div class="">1. What benchmarks does LLVM community use for compile-time study? I see CTMark, but is that the only one being analyzed?</div></div></div></blockquote>I used CTMark, which is a subset of the standard LLVM testsuite. We created CTMark some time ago specifically to make it a benchmark suite for compile-time studies with idea that new tests will be added in future. Usually it’s also a good idea to check compile time on established suites, e.g. SPEC, but this time I didn’t do it (building SPEC takes much longer than building CTMark).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">2. Is ASM parsing treated as a bottleneck in the flow? It is not the default in the compilation flow though.</div></div></div></blockquote>It depends - if there is a use case where it’s a bottleneck, I don’t see a reason not to look into it. But in my investigations I don’t remember seeing it as a bottleneck.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">3. Do we have a target here? how fast does LLVM want to be? </div></div></div></blockquote>It’s an open-ended goal. Ideally, compile-time should improve from release to release but in practice it’s almost impossible, because LLVM gets more and more features. My current focus is to identify bottlenecks (using CTMark or maybe some other tests) and try to optimize them one by one. Since we didn’t care much about compile time in the recent past, I think there should be plenty of low-hanging fruits here.</div><div><br class=""></div><div>Thanks,</div><div>Michael<br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class="gmail_quote">On Wed, Apr 12, 2017 at 8:22 AM, Mikhail Zolotukhin via llvm-dev<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class="">Hi,<div class=""><br class=""></div><div class="">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 :)</div><div class=""><br class=""></div><div class="">*** Current status ***</div><div class="">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).</div><div class=""><br class=""></div><div class="">*** Future work ***</div><div class="">There are still plenty of opportunities to make LLVM faster. Here is a list of some ideas that can further help compile-time:</div><div class=""><br class=""></div><div class="">- 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.</div><div class="">- 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.</div><div class="">- 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.</div><div class="">- 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.</div><div class="">- 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]).</div><div class="">- 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks for your time,</div><div class="">Michael</div><div class=""><div class=""><br class=""></div><div class="">[1] <a href="http://lists.llvm.org/pipermail/llvm-dev/2017-January/109188.html" target="_blank" class="">http://lists.llvm.org/<wbr class="">pipermail/llvm-dev/2017-<wbr class="">January/109188.html</a></div></div><div class="">[2]<span class="Apple-converted-space"> </span><a class="m_-7569083721501244892m_-3075486418410273754gmail-m_-1855108276665198409moz-txt-link-freetext" href="https://reviews.llvm.org/D31239" target="_blank">https://reviews.llvm.org/D3123<wbr class="">9</a></div><div class="">[3] <a href="https://reviews.llvm.org/D31843" target="_blank" class="">https://reviews.llvm.org/<wbr class="">D31843</a></div><div class="">[4] <a href="https://reviews.llvm.org/D31302" target="_blank" class="">https://reviews.llvm.org/<wbr class="">D31302</a></div><div class=""><br class=""></div><div class="">CTMark -Os:</div><div class=""></div></div><br class=""><div style="word-wrap: break-word;" class=""><div class=""></div><div class="">CTMark -O0-g:</div><div class=""></div></div><br class=""><div style="word-wrap: break-word;" class=""><div class=""></div><div class=""><br class=""></div></div><br class="">______________________________<wbr class="">_________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class=""><br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><i style="font-size: 12.8px;" class="">Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this mail are of my own and my employer has no take in it. </i><br class=""></div><div class="">Thank You.<br class="">Madhur D. Amilkanthwar</div></div></div></div></div></blockquote></div><br class=""></body></html>