
<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=""><div class=""><br class=""></div><div class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">this is about kicking-off regular compile-time tracking for LLVM and CLANG on the green dragon: <a href="http://lab.llvm.org:8080/green/view/Compile Time/" class="">http://lab.llvm.org:8080/green/view/Compile%20Time/</a>. The goal is to stay on top of compile-time issues immediately when they occur so they can be assessed rather than creeping in unnoticed. The methodology is simple: form a CTMark suite out of 10 “long” compiling tests of the LLVM test suite and track it closely for ARM64 O0g and Os. When there is a jump in compile-time of more than 2.5% in one of the tests an email notification will be sent to the committer and a bug will be filed in bugzilla. The 2.5% threshold is large enough to be above the noise level and should be motivating enough to root cause the issue. Also watch for spikes of >10% in O3 LTO. </div><div class=""><br class=""></div><div class="">There will be process and effort. Chris Matthews put together CTMark together with Michael and Matthias, and keeps the servers running and constantly improves tooling. Michael stepped up helping with the ongoing process of watching for issues and filing PRs until that part is automated. It will require the effort of everyone to control and possibly improve compile-time over time. And everybody is invited to root cause past regressions.</div><div class=""><br class=""></div><div class=""><div class="">The need for this work has been recognized by the communities and also externally. It has been observed more than once that llvm and clang are getting slower over time, for example in this thread: <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-March/096491.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-March/096491.html</a>. Phoronix reported recently compile-time slow downs in clang 3.9 vs 3.8: <a href="http://www.phoronix.com/scan.php?page=article&item=llvm-clang-39&num=4" class="">http://www.phoronix.com/scan.php?page=article&item=llvm-clang-39&num=4</a>. At the LLVM Developer Meeting Michael showed double digit compile-time increases in clang 3.7 and 3.8 in Os/O3 and O0 in his Loop Passes presentation (<a href="https://llvmdevelopersmeetingbay2016.sched.org/event/8Z0B/loop-passes-adding-new-features-while-reducing-technical-debt" class="">https://llvmdevelopersmeetingbay2016.sched.org/event/8Z0B/loop-passes-adding-new-features-while-reducing-technical-debt</a>):</div><div class=""><img apple-inline="yes" id="2A170F12-81FC-4141-8445-291633BECAF4" height="304" width="640" apple-width="yes" apple-height="yes" class="" src="cid:0114352C-550B-4B19-B70A-C56A42E85BE7@apple.com"></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The selection of 10 tests out of the LLVM tests invites criticism. The motivation here is to pick something “reasonable” and adjust as needed moving forward. Specifically this means running a wider set of tests from time to time and adjust the tests in CTMark either by adding more tests or by removing in-effective tests. Internally we also track a set of benchmarks and check for correlations of compile-time regressions to CTMark. And most importantly I think the shared interest and commitment of the community to compile-time will carry this forward.</div><div class=""><br class=""></div><div class="">Special thanks to Chris and Michael to get this started!</div><div class=""><br class=""></div><div class="">-Gerolf</div></div></body></html>