<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">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><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><div> </div><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></div><br>Yes, there should clearly be a relationship here. 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>