[llvm-dev] Queries Regarding Usage of PGOInstrumentation Passes instead of Deprecated ProfileInfo

Xinliang David Li via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 15 13:28:42 PDT 2018


On Wed, Aug 15, 2018 at 12:46 PM Malhar Thakkar <cs13b1031 at iith.ac.in>
wrote:

> Thank you so much for your response.
>
> On Wed, Aug 15, 2018 at 3:08 PM, Xinliang David Li <xinliangli at gmail.com>
> wrote:
>
>>
>>
>> On Wed, Aug 15, 2018 at 7:36 AM Malhar Thakkar via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hey all,
>>>
>>> I have a piece of code (written in LLVM 2.8) which uses profiling
>>> results produced by ProfileInfo. It essentially computes the number of
>>> iterations performed by a loop from the profiling information available.
>>> The code snippet in my pass looks something like this.
>>>
>>>   BasicBlock *header = loop->getHeader();
>>>   ProfileInfo &pi = getAnalysis< ProfileInfo >();
>>>   for(pred_iterator i=pred_begin(header), e=pred_end(header); i!=e; ++i)
>>>   {
>>>     BasicBlock *pred = *i;
>>>
>>>     const double edgeCount = *pi.getEdgeWeight*( ProfileInfo::Edge(pred,header) );
>>>     */* Some code */*
>>>   }
>>>
>>> Now, since ProfileInfo has been deprecated and we have
>>> PGOInstrumentation passes along with BranchProbability and BlockFrequency,
>>> I wish to update the above snippet, in particular, obtaining the edge
>>> weights (highlighted in the code above) using the new tools.
>>>
>>> In order to do that, I'm first generating edge count profile by the
>>> PGOInstrumentationGen pass and then interpreting the edge count profile
>>> with PGOInstrumentationUse.
>>>
>>> In the original code, where I had
>>> au.addRequired< ProfileInfo >(), I now have
>>>
>>>
>>> *au.addRequired< BlockFrequencyInfoWrapperPass >();au.addRequired<
>>> BranchProbabilityInfoWrapperPass >();*
>>> Now, I have the following queries.
>>>
>>>    - How do I use the edge count and branch weights data obtained using
>>>    PGOInstrumentationUse in my pass and replace the *getEdgeWeight()*
>>>    from ProfileInfo?
>>>
>>>
>> You can do
>>  BPI.getEdgeProbability(Src, Dest).scale(BFI.getBlockProfileCount(Src));
>>
>
> I tried doing this but there are some semantic issues that I'm facing.
> There is a loop in my program which I know is a hot loop since it is the
> only loop inside the function main() and essentially, all the computations
> are performed within this function via function calls. However, when I
> perform getBlockProfileCount(Src) where Src is the preheader of the said
> loop, I find that it returns zero and upon further investigation, I found
> that the entry frequency for the function was 6148904414811 and the block
> frequency for the aforementioned preheader block was 6148904394768 and
> after performing udiv, since it is an integer division,
> getBlockProfileCount(Src) returned zero and hence, my code infers that it
> is not a hot loop when in fact it clearly is.
>
> Any suggestions on why this may be happening?
>

What is function entry's profile count? Note it is different from entry
frequency (which is synthetic). You can find the function entry's count
from entry's prof meta data. There is also an API to get it.


>
>>
>>>
>>>    - If I call *getBlockProfileCount() *from the BlockFrequency pass,
>>>    will that give me the data read during PGOInstrumentationUse or data based
>>>    on static analysis? In other words, does the data obtained during
>>>    PGOInstrumentationUse "propagate" to BlockFrequency and BranchProbability?
>>>
>>>
>>> Correct.
>>
> Just to confirm, when you say "correct", do you mean to say that the
> information in fact does get propagated to BlockFrequency and
> BranchProbability? If yes, how does the propagation take place?
>

Branch probability info analysis pass will use the profile meta data (read
in from profile data and annotated in the IR) and use that to compute
branch probability. The block frequency propagation pass uses BPI info to
compute relative block frequencies.   The actual profile count of the
function entry is kept, and a block's actual profile count can then be
recomputed using Entry Frequency, block frequency, and the entry count data.

David



>
>
> Thank you.
>
> Regards,
> Malhar
>
>>
>> David
>>
>>
>>
>>> Thank you.
>>>
>>>
>>> Regards,
>>> Malhar
>>>
>>>
>>>
>>>
>>>>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180815/97682c09/attachment.html>


More information about the llvm-dev mailing list