[clang] [clang-tools-extra] [compiler-rt] [PGO] Exposing PGO's Counter Reset and File Dumping APIs (PR #76471)

[Teresa Johnson via cfe-commits]

teresajohnson wrote:

> I realized one problem during testing IRPGO (thanks again for the suggestion @minglotus-6 !).
> 
> A function's control flow may change between `-fprofile-generate` and `-fprofile-use` when we make use of definitions in the new header. For example, one may have the following code:
> 
> ```c
> #include "profile/instr_prof_interface.h"
> 
> void main() {
>    ...
>   if (__llvm_profile_dump())
>     return error;
>   
>   cleanup();
> }
> ```
> 
> During `-fprofile-generate`, `__llvm_profile_dump` is a declared name and main's control flow includes a branch to `return error;`. During `-fprofile-use`, `__llvm_profile_dump()` is replaced by `(0)` and the frontend eliminates the `if` statement and the branch to `return error`. Such control flow change can lead to PGO warnings (hash mismatch).
> 
> I think it may be OK to keep the PR this way because the new macros can potentially cause control flow changes directly as well. The documentation is updated (https://github.com/llvm/llvm-project/pull/76471/files#diff-7389be311daf0b9b476c876bef04245fa3c0ad9337ce865682174bd77d53b648R2908) to advise against using these APIs in a program's hot regions and warn about possible impact on control flow.
> 
> Do you all think this is reasonable?

That's probably ok, as it doesn't make sense to do dumping etc in a hot region of code anyway. An alternate suggestion is to make these functions real functions that simply return 0 instead of #defined to 0. But that may not avoid the issue described above because early inlining will likely inline and simplify the code before IR PGO matching anyway.


https://github.com/llvm/llvm-project/pull/76471