<div dir="ltr"><div dir="ltr">Hi Renato,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 1:03 AM Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.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="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" 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></div></blockquote><div><br></div><div>Thank you :-) </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 class="gmail_quote"><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></div></blockquote><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 class="gmail_quote"><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></div></div></blockquote><div>Good point! We are aware that LLVM Test Suite is too "SPEC-alike" and lean toward scientific computation rather than real-world use cases. So we actually did experiments on the V8 javascript engine, which is absolutely a huge code base and a good real-world example. And it showed a 10~13% speed improvement on optimization + codegen time with up to 4% of target performance overhead (Note that due to some hacky reasons, for many of the V8 source files, over 80% or even 95% of compilation time was spent on frontend, so measuring by total compilation time will be heavily skewed and unable to reflect the impact of this feature)</div><div><br></div><div>Best</div><div>-Min</div><div> </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 class="gmail_quote"><div><div><br></div><div>cheers,</div><div>--renato</div><div></div></div></div></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></div>