Previously, we only checked for duplicate zero entries when merging a MemOPSize table (see D92074), but a user recently provided a reproducer demonstrating that other entries can also be duplicated. As demonstrated by the test in this patch, PGOMemOPSizeOpt can potentially generate invalid IR for non-zero, non-consecutive duplicate entries. This seems to be a rare case, since the duplicate entry is often below the threshold, but possible. This patch extends the existing warning to check for any duplicate values in the table, both in the optimization and in llvm-profdata. We're hoping that this expanded warning will catch more examples of this behavior so we can diagnose the root cause of these duplicate entries more easily.
Details
Diff Detail
Unit Tests
Time | Test | |
---|---|---|
40 ms | x64 debian > LLVM.CodeGen/MIR/AArch64::mirnamer.mir |
Event Timeline
llvm/lib/Transforms/Instrumentation/PGOMemOPSizeOpt.cpp | ||
---|---|---|
318–319 | Why not make this a full diagnostic error/warning? Is this something a user could encounter in the wild? | |
318–319 | ||
llvm/test/tools/llvm-profdata/invalid-profile-gen-dup-entries.proftext | ||
5 | It seems strange that this is emitted as a warning rather than an error. Is there a case where this warning can be safely ignored? |
llvm/lib/Transforms/Instrumentation/PGOMemOPSizeOpt.cpp | ||
---|---|---|
318–319 |
Well, my understanding is that invalid profile data is usually skipped with a diagnostic. I don't want this error to be out of line with other profile data diagnostics. If something more severe is usually emitted, then we should change this error as well.
This does occur in the wild, though it's very rare. We originally discovered this issue when a user sent us invalid bitcode which we determined had been generated by this pass. | |
llvm/test/tools/llvm-profdata/invalid-profile-gen-dup-entries.proftext | ||
5 | My original intention was to make this an error (see the earlier patch), but my experiments seem to indicate that very few users 1) encounter the bug that generates this invalid profile data and 2) have the correct conditions to force the MemOpSize pass to use that invalid profile data. If the 3 largest counts aren't invalid, it seems like generating invalid bitcode is unlikely. We also haven't seen many users report this diagnostic to us. That said, while I'm comfortable leaving it as a warning, but I would still prefer this to be an error. If it's an error, we would likely get more data to reproduce this issue. @xur, do you have any thoughts on this? |
llvm/lib/ProfileData/InstrProfWriter.cpp | ||
---|---|---|
536 | Oh I missed this the first time. | |
llvm/lib/Transforms/Instrumentation/PGOMemOPSizeOpt.cpp | ||
318–319 |
If the compiler generated invalid bitcode then IMO we should definitely emit an error. Or maybe we can turn this into an assert at least? Maybe there is something I'm missing because I'm not familiar with MemOP. |
llvm/lib/Transforms/Instrumentation/PGOMemOPSizeOpt.cpp | ||
---|---|---|
318–319 | OK, that makes sense to me. I'll change it in the next update. |
- Correct existence check
- Change debug note to an error
- Update tests to look for error
llvm/lib/Transforms/Instrumentation/PGOMemOPSizeOpt.cpp | ||
---|---|---|
318–319 | I've changed this to a simple error, but there is an argument that it should be an optimization remark. Thoughts? |
Oh I missed this the first time.