Issue |
133912
|
Summary |
fdebug-info-for-profiling flag unexpectedly affects code generation
|
Labels |
debuginfo
|
Assignees |
|
Reporter |
jmorse
|
Here's a godbolt link showing a difference in codegen produced by `-fdebug-info-for-profiling`: https://godbolt.org/z/sx8TEdPcb . An extra/spurious `xor` appears with the flag, and the identity of one of the functions changes. As far as I'm aware, `-fdebug-info-for-profiling` is intended to affect only the production of debugging information, not the generation of code to make it more amenable to debugging or profiling, which would make this a bug.
The (heavily reduced sorry) reproducer, for completeness:
```
struct str {
str(char *);
};
using str2 = str;
struct foo {
foo(str2);
};
struct bar {
struct fail : foo {
char msg;
fail() : foo(&msg) {}
};
void clear() { fail(); }
};
struct baz : bar {
void set(bool) { clear(); }
};
baz operator<<(baz _a, char) { _a.set(0); }
```
I dug into why this happens, and it comes in three stages:
* The Inliner has an [`EnableDeferral` flag](https://github.com/llvm/llvm-project/blob/08dda4dcbf6427e357830d9c7f7ac3b422fc75f6/llvm/lib/Analysis/InlineAdvisor.cpp#L422) that makes the inliner less aggressive for certain static functions, so that they're small enough to be entirely inlined and eliminated from a file,
* This flag is enabled during pass-construction [if PGO options are enabled](https://github.com/llvm/llvm-project/blob/2044dd07da99714bbeb801bafe6dd5179493fd48/llvm/lib/Passes/PassBuilderPipelines.cpp#L939)
* PGO options are enabled if `-fdebug-info-for-profiling` [is enabled](https://github.com/llvm/llvm-project/blob/f137c3d592e96330e450a8fd63ef7e8877fc1908/clang/lib/CodeGen/BackendUtil.cpp#L870)
Thus, through a chain of decisions, we end up with different inlining choices because of debugging information. The most suspicious to me is the last, enabling PGO options if profiling debug-info is desired. This was added in c76a27e3257c54948df7fa969042d to ensure that the add-discriminator pass was enabled with the `-fdebug-info-for-profiling`. I would imagine that we need to directly write that logic somewhere, rather than using PGOOptions as a proxy.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs