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

[Reid Kleckner via cfe-dev]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210519/d927d50a/attachment.html>