<div dir="ltr">We would like to propose a new feature to disable optimizations on IR Functions that are considered “cold” by PGO profiles. The primary goal for this work is to improve code optimization speed (which also improves compilation and LTO speed) without making too much impact on target code performance.<br><br>The mechanism is pretty simple: In the second phase (i.e. optimization phase) of PGO, we would add `optnone` attributes on functions that are considered “cold”. That is, functions with low profiling counts. Similar approach can be applied on loops. The rationale behind this idea is pretty simple as well: If a given IR Function will not be frequently executed, we shouldn’t waste time optimizing it. Similar approaches can be found in modern JIT compilers for dynamic languages (e.g. Javascript and Python) that adopt a multi-tier compilation model: Only “hot” functions or execution traces will be brought to higher-tier compilers for aggressive optimizations.<br><br>In addition to de-optimizing on functions whose profiling counts are exactly zero (`-fprofile-deopt-cold`), we also provide a knob (`-fprofile-deopt-cold-percent=<X percent>`) to adjust the “cold threshold”. That is, after sorting profiling counts of all functions, this knob provides an option to de-optimize functions whose count values are sitting in the lower X percent.<br><br>We evaluated this feature on LLVM Test Suite (the Bitcode, SingleSource, and MultiSource sub-folders were selected). Both compilation speed and target program performance are measured by the number of instructions reported by Linux perf. The table below shows the percentage of compilation speed improvement and target performance overhead relative to the baseline that only uses (instrumentation-based) PGO.<br><br>Experiment Name               Compile Speedup           Target Overhead<br>DeOpt Cold Zero Count                5.13%                             0.02%<br>DeOpt Cold 25%                           8.06%                             0.12%<br>DeOpt Cold 50%                           13.32%                           2.38%<br>DeOpt Cold 75%                           17.53%                           7.07%<br><br>(The “DeOpt Cold Zero Count” experiment will only disable optimizations on functions whose profiling counts are exactly zero. Rest of the experiments are disabling optimizations on functions whose profiling counts are in the lower X%.)<br><br>We also did evaluations on FullLTO, here are the numbers:<br><br>Experiment Name               Link Time Speedup         Target Overhead<br>DeOpt Cold Zero Count                10.87%                           1.29%<br>DeOpt Cold 25%                           18.76%                           1.50%<br>DeOpt Cold 50%                           30.16%                           3.94%<br>DeOpt Cold 75%                           38.71%                           8.97%<br><br>(The link time presented here included the LTO and code generation time. We omitted the compile time numbers here since it’s not really interesting in LTO setup)<br><br>From the above experiments we observed that compilation / link time improvement scaled linearly with the percentage of cold functions we skipped. Even if we only skipped functions that never got executed (i.e. had counter values equal to zero, which is effectively “0%”), we already had 5~10% of “free ride” on compilation / linking speed improvement and barely had any target performance penalty.<br><br>We believed that the above numbers had justified this patch to be useful on improving build time with little overhead.<br><br>Here are the patches for review:<br>* Modifications on LLVM instrumentation-based PGO: <a href="https://reviews.llvm.org/D87337">https://reviews.llvm.org/D87337</a> <br>* Modifications on Clang driver: <a href="https://reviews.llvm.org/D87338">https://reviews.llvm.org/D87338</a> <br><br>Credit: This project was originally started by Paul Robinson <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> and Edward Dawson <<a href="mailto:Edd.Dawson@sony.com">Edd.Dawson@sony.com</a>> from Sony PlayStation compiler team. I picked it up when I was interning there this summer.<br clear="all"><div><br></div><div>Thank you for your reading.</div><div>-Min</div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Min-Yih Hsu</div><div>Ph.D Student in ICS Department, University of California, Irvine (UCI).<br></div></div></div></div>