[PATCH] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

[Xinliang David Li via cfe-commits]

For the longer term, one possible solution is to make FE based
instrumentation only used for coverage testing which can be turned on
with -fcoverage-mapping option (currently, -fcoverage-mapping can not
be used alone and must be used together with
-fprofile-instr-generate). To summarize:

A. Current behavior:
-----------------------
1) -fprofile-instr-generate turns on FE based instrumentation
2) -fprofile-instr-generate -fcoverage-mapping turns on FE based
instrumentation and coverage mapping data generation.
3) -fprofile-instr-use=<..> assumes profile data from FE instrumentation.


B. Proposed new behavior:
--------------------------------
1) -fprofile-instr-generate turns on IR late instrumentation
2) -fcoverage-mapping turns on FE instrumentation and coverage-mapping
3) -fprofile-instr-generate -fcoverage-mapping result in compiler warning
4) -fprofile-instr-use=<> will automatically determine how to use the
profile data.

B.2) above can be done today for improved usability. B.1) needs a
transition period before  the IR based instrumentation becomes
stablized (and can be flipped to the default).  During the transition
period, the behavior of 1) does not change, but a cc1 option can be
used to turn on IR instrumentation (as proposed by Sean).


In the real longer term, I think IR based instrumentation can also be
used for coverage testing too (by disabling some pre-optimizations and
pre-inlining needed for PGO purpose) -- but this is a different topic
to be discussed.

thanks,

David









On Thu, Jan 21, 2016 at 7:40 PM, Sean Silva <chisophugis at gmail.com> wrote:
> silvas added a comment.
>
> @bogner btw, did you say that at Apple you guys have a requirement of supporting existing profdata? I.e. users can pass older profdata to a newer compiler?
>
> Realistically, it would be nice if our PGO offering defaulted to the IR stuff (since it seems like it is going to be the focus of optimization work and so is likely to be our best-performing offering). But if we need to support profdata across versions of clang, that puts us in a thorny situation because suddenly `clang -c foo.c -fprofile-instr-use=old-profdata-from-frontend-instrumentation.profdata` has a default meaning equivalent to `clang -c foo.c -fir-level-instrumentation -fprofile-instr-use=old-profdata-from-frontend-instrumentation.profdata` (setting aside the flag name issue), which is a case we want to error on due to mismatch between frontend and IR-level instrumentation.
>
>
> http://reviews.llvm.org/D15829
>
>
>