[cfe-dev] Status of IR vs. frontend PGO (fprofile-generate vs fprofile-instr-generate)

[Xinliang David Li via cfe-dev]

On Wed, May 19, 2021 at 7:48 PM Alex Lorenz <aleksei_lorenz at apple.com>
wrote:

>
>
> On May 19, 2021, at 4:24 PM, Xinliang David Li <xinliangli at gmail.com>
> wrote:
>
>
>
> On Wed, May 19, 2021 at 4:14 PM Vedant Kumar <vsk at apple.com> wrote:
>
>>
>>
>> On May 19, 2021, at 3:11 PM, Xinliang David Li <xinliangli at gmail.com>
>> wrote:
>>
>>
>>
>> On Wed, May 19, 2021 at 1:31 PM Alex Lorenz via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> > On May 19, 2021, at 1:18 PM, Reid Kleckner via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>> >
>>> > Hi folks,
>>> >
>>> > I wanted to make some improvements to code coverage, which uses
>>> frontend profile instrumentation. Is anyone still using frontend PGO for
>>> optimization (not coverage), or has everyone moved to IR PGO for that?
>>> >
>>> > Here are the existing modes as I understand them:
>>> >
>>> > 1. Frontend PGO: -fprofile-instr-generate / use. Code in
>>> clang/lib/CodeGen/CodeGenPGO.cpp inserts PGO counter update intrinsics.
>>> This happens before optimization. This is very source directed.
>>> >
>>> > 2. Coverage: -fprofile-instr-generate -fcoverage-mapping. This is
>>> basically frontend PGO, plus some extra coverage mapping data to map from
>>> counters back to precise source locations.
>>> >
>>> > 3. IR PGO: -fprofile-generate. The LLVM IR pass
>>> llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp is responsible
>>> for inserting calls to the counter update intrinsics at some specific point
>>> in the optimization pipeline. IIUC, this is done after the "pre-inliner"
>>> pass and other simplification passes so that there are fewer counter
>>> updates and a bit more precision.
>>> >
>>> > 4. Context sensitive PGO: -fcs-profile-generate. This is basically the
>>> same as IR PGO, except it happens after regular inlining, so you can use it
>>> as a "second round" of PGO: use IR PGO first, get profile guided inlinings,
>>> profile again, and use that to influence code layout or further inlining.
>>> >
>>> > ---
>>> >
>>> > Is anyone using the first mode, frontend PGO, or has everyone migrated
>>> to IR PGO already? It seems to me that the main use case for frontend PGO
>>> is really just coverage, and we should consider deprecating frontend PGO.
>>> In Chrome, we accidentally started using frontend PGO instead of IR PGO,
>>> and found that IR PGO was better.
>>> >
>>>
>>> Yes, we use the frontend PGO in Apple clang in Xcode. I’m curious
>>> though, what kind of improvements did you see with IR PGO?
>>>
>>
>> +Vedant Kumar <vsk at apple.com>
>>
>> Any other reason you are using frontend PGO for performance?  IR PGO has
>> other advantages as well: 1) better performance in training run; 2) better
>> value profiling support; and 3) smaller raw profile data size.
>>
>>
>> Michael (just cc'd) and Alex L. have more context about the AppleClang
>> release process and would be better suited to answer.
>>
>> Historically, we've expected there to be some amount of source drift
>> between the latest PGO/training build available from CI and the release
>> tag. FE PGO is supposed to degrade gracefully when source drift occurs, and
>> I believe we rely on that feature.
>>
>
> Both IR and Frontend PGO use content based hashing for profile lookup. Is
> there anything in FE PGO which makes it more tolerant to source drifts?
>
>
> This is an important issue for us, but I don’t know if and how the
> frontend PGO is more tolerant to that. I think we need to do some more
> analysis on our end to see what specifically we need out of frontend PGO
> that isn’t well served by IR PGO.
>
> As far the possible deprecation of frontend PGO, will that imply that the
> `-fprofile-instr-generate / use` options will get removed, or will they
> still be supported but will leverage IR PGO instead?
>

I assume it means making -fprofile-instr-generate and alias to
-fprofile-generate which does IR PGO instrumentation.

-fprofile-instr-use and -fprofile-use are pretty much the same as of today
as the compiler can tell if the profile is from LLVM or FE.

David


>
>
> David
>
>
>>
>> vedant
>>
>> Deprecating frontend-PGO (and making it for coverage testing only) would
>> be desirable as Reid said.
>>
>> David
>>
>>
>>
>>>
>>> > I'm asking because I would like to make code coverage builds faster
>>> and smaller, and supporting PGO with the same codepaths makes that
>>> complicated.
>>> >
>>> > Reid
>>> > _______________________________________________
>>> > cfe-dev mailing list
>>> > cfe-dev at lists.llvm.org
>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210519/60132146/attachment-0001.html>