<div dir="ltr"><div>Hi Taewook,</div><div><br></div>There is no reason not do use BFI in non-PGO mode. My current priority is to improve PGO performance and I wanted to isolate this as much as possible - hence it is turned on only in PGO mode.<div><br></div><div>- Easwaran</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 10:54 AM, Taewook Oh <span dir="ltr"><<a href="mailto:twoh@fb.com" target="_blank">twoh@fb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Thank you Easwaran for landing a great diff that enables the use of block frequency information in inliner. As of now, it seems that inliner can exploit the information only when profile data is available. However, instructions such as __builtin_expect
 may set branch weight metadata as well, which is useful for inliner. </div>
<div><br>
</div>
<div>I think this problem can be addressed by letting llvm::getInlineCost function to use BlockFrequencyAnalysis regardless of availability of profile data, and making CallAnalyzer::updateThreshold to use callsite frequency instead of callsite count. Is there
 a reason that we allow inliner to use block frequency information only when profile data is given? </div>
<div><br>
</div>
<div>Thanks,</div>
<div>Taewook</div>
</div>

</blockquote></div><br></div>