<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 1:07 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Mar 24, 2015 at 1:03 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The design is basically to augment the existing frequency data with one 64bit data which is the global hotness of the function entry (e.g. it be the entry execution count). With the execution count available, the BB  count (or global hotness if you will) is simply:<div><br></div><div>  count(BB)  = freq (BB) * count(ENTRY)/freq(ENTRY)</div><div><br></div><div>You can view count(ENTRY) as an extension to the current 'hot'/'cold' attribute</div></div></blockquote><div><br></div></span><div>Yes, this is what I'm saying the current design was aiming for. Is this what you're now suggesting, or are you suggesting something different?</div><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>I am not sure what current design are you referring to.  What I am saying is that we need to represent 'count(ENTRY)' for IPA purpose, which is currently missing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Note that for IPA, callsite count is obtained from enclosing BB's count.</div></div></blockquote></span></div><br>Yes, there should clearly be a relationship here. </div></div></blockquote><div><br></div><div>By the definition of 'count', it can be used for IPA. This is the key difference to 'Freq'.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">One way I would like to see this tested is to look at the relative error at each level -- if we compute the global "count" as you describe for a callsite's BB, and aggregate it with all other callsite BBs, we should get something close to function's global value. If we get wildly different results, there is probably some flaw in the algorithm used.</div></div></blockquote><div><br></div><div>We don't need to 'compute' global count -- with PGO, it is already there. We just need to keep it without dropping it.</div><div><br></div><div>With PGO, the current block frequency computation flow is roughly like this:</div><div><br></div><div>1) read the raw profile count from profile data file. </div><div>2) compute the true/false branch target weight from the raw profile data, and create MD_prof. Note that with capping and other things, the data associated with MD_prof can only be used as branch probability </div><div>3) Invoke BranchProbabilityInfo analysis pass. Converting MD_prof into CFG level branch probability data (weight) with more capping</div><div>4) Invoke BlockFrequencyInfo analysis pass -- this pass sole relies on branch probability and assumes Freq(ENTRY) = 1 (for fraction representation).</div><div>5) (roughly) Scale up the Freq(BB) data in 4) by making the Integer freq of BB with the the lowest fractional frequency to be 1</div><div><br></div><div><br></div><div>With the proposed change, we just need to add one more step</div><div>2.1) Record the count(ENTRY) for the function as a meta data.</div><div><br></div><div>David</div><div><br></div><div><br></div><div> </div></div><br></div></div>