[PATCH] D70676: [DebugInfo] Don't repeatedly created undef DBG_VALUEs during machine-sinking
Jeremy Morse via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 12 04:24:59 PST 2019
jmorse reopened this revision.
jmorse added a comment.
This revision is now accepted and ready to land.
Too lazy on the earlier explanation there sorry. To elaborate: I thought I'd accounted for nondeterminism in the two loops in reinsertSunkDebugDefs, but both were a bit broken:
For the outer loop, because we're only ever placing DBG_VALUEs after pre-determined instructions like this:
inst1
<--- insert DBG_VALUE here
inst2
<--- insert DBG_VALUE here
I'd assumed that it didn't matter what order that happens in. However, on second thoughts if an instruction defines more than one vreg, groups of DBG_VALUEs associated with different vregs from an instruction could change order.
For the inner loop, I was moving elements into a vector and then sorting them, based on the "DebugVariable" classes `operator<`. However, it turns out that compares pointers, and more generally it seems metadata doesn't support being ordered.
For both of these problems I've now switched to MapVector and SetVector respectively; the insertion order is defined by MachineSinking iterating over basic blocks (which is stable AFAIUI), and MachineSinking::ProcessBlock walking through the block backwards, which is also stable.
In the output from hans' reproducer, packs of DBG_VALUEs were being re-ordered, but in a way that didn't change the meaning of any variable location. I don't know why that led to changes in the layout of location lists (again, the meaning was the same), but either way the re-ordering is bad.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70676/new/
https://reviews.llvm.org/D70676
More information about the llvm-commits
mailing list