[LLVMdev] RFC - Improvements to PGO profile support

Chandler Carruth chandlerc at google.com
Tue Mar 24 13:07:03 PDT 2015

On Tue, Mar 24, 2015 at 1:03 PM, Xinliang David Li <xinliangli at gmail.com>

> 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:
>   count(BB)  = freq (BB) * count(ENTRY)/freq(ENTRY)
> You can view count(ENTRY) as an extension to the current 'hot'/'cold'
> attribute

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?

> Note that for IPA, callsite count is obtained from enclosing BB's count.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150324/121d6170/attachment.html>

More information about the llvm-dev mailing list