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

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/801b74a3/attachment.html>