[LLVMdev] RFC - Improvements to PGO profile support

[Xinliang David Li]

On Tue, Mar 24, 2015 at 11:29 AM, Chandler Carruth <chandlerc at google.com>
wrote:

> Sorry I haven't responded earlier, but one point here still doesn't make
> sense to me:
>
> On Tue, Mar 24, 2015 at 10:27 AM, Xinliang David Li <davidxl at google.com>
> wrote:
>
>> Diego and I have discussed this according to the feedback received. We
>> have revised plan for this (see Diego's last reply).  Here is a more
>> detailed re-cap:
>>
>> 1) keep MD_prof definition as it is today; also keep using the
>> frequency propagation as it is (assuming programs with irreducible
>> loops are not common and not important. If it turns out to be
>> otherwise, we will revisit this).
>> 2) fix all problems that lead to wrong 'frequency/count' computed from
>> the frequency propagation algorithm
>>    2.1) relax 32bit limit
>>
>
> I still don't understand why this is important or useful.... Maybe I'm
> just missing something.
>
> Given the current meaning of MD_prof, it seems like the result of limiting
> this to 32-bits is that the maximum relative ratio of probabilities between
> two successors of a basic block with N successors is (2 billion / N):1 --
> what is the circumstance that makes this resolution insufficient?
>
> It also doesn't seem *bad* per-se, I just don't see what it improves, and
> it does cost memory...
>

right -- there is some ambiguity here -- it is needed if we were to change
MD_prof's definition to represent branch count.  However, with the new
plan, the removal of the limit only applies to the function entry count
representation planned.

David


>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150324/4ecdf1f6/attachment.html>