Remove false positve debug location losses caught by Debugify
The problem of “false positive results” in Debugify reports was discussed at one of the LLVM Dev meetings. This RFC aims at solving this problem for reports about lost Debug Locations (instruction source locations).
Debugify utility, is a pair of IR passes, where the first one runs before an optimization pass and the second one runs after it. It has two modes:
- Synthetic mode (debugify) - check preservation of the artificially added debug info
- Original mode (verify-debuginfo-preserve) - check preservation of the debug info previously produced by compiler (with -g option)
First debugify pass records the DebugInfo state of the code in the following way:
- Synthetic mode - adds artificial debug info to each possible location (ex. DebugLoc to each instruction)
- Original mode - collects existing debug info in the code (ex. saves DebugLoc of each instruction)
Second debugify pass checks the state of debug info in the code, after the optimization, and then
compares it to the state before the optmization, and then reports the losses:
- Synthetic mode - checks if each possible location in code, contains corresponding debug-info (ex. each instruction should have a DebugLoc)
- Original mode - collects existing debug info in the code and compares to the saved state, before the pass (ex. if instruction had DebugLoc before the pass, it should have it after the pass)
DebugLoc drop, but not DebugLoc loss
There are several scenarios where debug locations are dropped, but should not be reported by Debugify as losses:
- instruction’s DebugLoc should be dropped if it cannot be unambiguously determined (according to How-to-update-debug-info document)
- instruction’s DebugLoc is copied from an other instruction (loss should not be reported for both instructions)
In my opinion, those cases should not be treated as losses, since DebugLocs are explicitly updated, but couldn’t be reconstructed.
My proposal, for resolving this, is to add a flag to the Instruction (
droppedLocation), which should be set if the DebugLoc is explicitly set to empty for that instruction. Then, during Debugify analysis, we should not report DebugLoc loss if instruction’s DebugLoc is explicitly updated (by checking the flag). (RFC patch)
Proposed solution was tested by compiling clang-14 with
-fverify-debuginfo-preserve. The results are shown bellow (eliminated around 65% of reported DebugLoc losses).
|LLVM Pass Name||Number of losses (before)||Number of losses (after)||Percentage of eliminated|
I am not sure if there is a better way for resolving this, maybe without changing Instruction class implementation.
Please, share your thoughts.