<div dir="ltr">Hi Tobias and Dominique,<div><br></div><div>I didn't evaluate the impact on code size in the first place since it was not my primary goal. But thanks to the design of LLVM Test Suite benchmarking infrastructure, I can call out those numbers right away.</div><div><br></div><div>(Non-LTO)</div><div>Experiment Name Code Size Increase Percentage</div><div>DeOpt Cold Zero Count 5.2%</div><div>DeOpt Cold 25% 6.8%</div><div>DeOpt Cold 50% 7.0%</div><div>DeOpt Cold 75% 7.0%</div><div><br></div><div>(FullLTO)</div><div><div>Experiment Name Code Size Increase Percentage</div><div>DeOpt Cold Zero Count 4.8%</div><div>DeOpt Cold 25% 6.4%</div><div>DeOpt Cold 50% 6.2%</div><div>DeOpt Cold 75% 5.3%</div></div><div><br></div><div>For non-LTO its cap is around 7%. For FullLTO things got a little more interesting where code size actually decreased when we increased the cold threshold, but I'll say it's around 6%. To dive a little deeper, the majority of increased code size was (not-surprisingly) coming from the .text section. The PLT section contributed a little bit, and the rest of sections brealey changed.</div><div><br></div><div>Though the overhead on code size is higher than the target performance overhead, I think it's still acceptable in normal cases. In addition, David mentioned in D87337 that LLVM has used similar techniques on code size (not sure what he was referencing, my guess will be something related to hot-cold code splitting). So I think the feature we're proposing here can be a complement to that one. </div><div><br></div><div>Finally: Tobias, thanks for evaluating the impact on Clang, I'm really interested to see the result.</div><div><br></div><div>Best,</div><div>Min</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 3:26 AM Tobias Hieta <<a href="mailto:tobias@plexapp.com">tobias@plexapp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hello,<div dir="auto"><br></div><div dir="auto">We use PGO to optimize clang itself. I can see if I have time to give this patch some testing. Anything special to look out for except compile benchmark and time to build clang, do you expect any changes in code size?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020, 10:03 Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, 9 Sep 2020 at 01:21, Min-Yih Hsu via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div><div>Hi Min (Paul, Edd),</div><div><br></div><div>This is great work! Small, clear patch, substantial impact, virtually no downsides.</div><div><br></div><div>Just looking at your test-suite numbers, not optimising functions "never used" during the profile run sounds like an obvious "default PGO behaviour" to me. The flag defining the percentage range is a good option for development builds.</div><div><br></div><div><div>I imagine you guys have run this on internal programs and found beneficial, too, not just the LLVM test-suite (which is very small and non-representative). It would be nice if other groups that already use PGO could try that locally and spot any issues.</div><div><br></div><div>cheers,</div><div>--renato</div><div></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="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>