Currently, if a stack spill location is overwritten to by another spill instruction, nothing notices and any variables located in that slot are not terminated. This can lead to incorrect variable values being reported by debuggers, see PR42772 [0]. The test added replicates this scenario. We should notice this memory-clobber and terminate variable locations when it happens.
Scanning for clobbered spill locations happens before scanning for new spills/restores, terminates open ranges and adds DBG_VALUE $noregs. The early scanning is because the current spill/restore logic appears to quit after moving one location, even if there could be multiple candidates, and I don't want to go near that right now. One function gets refactored into two: the old isSpillInstruction performed a few register liveness tests to see whether an instruction _looked_ like a spill, wheras all we're interested in for terminating existing locations is whether there's a stack write at all.
Note that this creates some slight differences between how registers and spill locations are treated: right now DbgEntityHistoryCalculator will spot register clobbers and terminate any variable locations that have been overwritten, thus manually inserting DBG_VALUE $noreg isn't necessary for registers in LiveDebugValues. IMO it's much harder for DbgEntityHistoryCalculator to spot memory/stack clobbers (it would have to dig into DIExpressions) wheras in LiveDebugValues we already have that information to hand.
I've left quite a lot of machine-code in the MIR test where it could be simpler; IMHO it's good to have a slightly larger test here just in case LiveDebugValues tries to do something clever in the future and gets it wrong.
There's a fractional increase in scope-bytes-covered by 0.05%, it's not completely clear to me why unfortunately D:
out of curiosity: is @MI legal doxygen?