[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 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?

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/54c5c9ed/attachment-0001.html>