Check that dbg.assign intrinsics are not accidently converted into dbg.value intrinsics.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM with nit.
I find the reproducer utterly fascinating -- because of the leak, the variable is partially promoted, and the store in the condition block dominates the leak site so there's no loop-exit-PHI that a dbg.value gets attached to. Instead the last dbg.value is inside the loop, and gets set to undef when the loop is loop-reduced away. LowerDbgDeclare has a partial save by instrumenting the call site, but that's something dbg.assign does better.
Will this stop working if the fix to TryToSimplifyUncondBranchFromEmptyBlock in D133310 doesn't land?
llvm/test/DebugInfo/Generic/assignment-tracking/loop-deletion/dead-loop.ll | ||
---|---|---|
22 | I'd suggest more detail in what the operands to dbg.assign are, just to confirm it isn't stripped of all information. Ensuring it still refers to the alloca would be good. |
(One wonders why the dbg.values get set to undef when the sunk store still retains a value -- possibly the PHI put in by lcssa gets RAUW'd but the source value doesn't? This raises the possibility that scenarios like this might benefit from forward salvaging, i.e. "we know this value is dead, but something using it isn't, so re-point the dbg intrinsics at that).
I'd suggest more detail in what the operands to dbg.assign are, just to confirm it isn't stripped of all information. Ensuring it still refers to the alloca would be good.