[all-commits] [llvm/llvm-project] d9c9a4: [DebugInfo] Avoid register coalesing unsoundly cha...

[Jeremy Morse via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: d9c9a4e48d286a04d09a8fdea87f486a9ec02cd0
      https://github.com/llvm/llvm-project/commit/d9c9a4e48d286a04d09a8fdea87f486a9ec02cd0
  Author: Jeremy Morse <jeremy.morse at sony.com>
  Date:   2019-11-25 (Mon, 25 Nov 2019)

  Changed paths:
    M llvm/lib/CodeGen/RegisterCoalescer.cpp
    A llvm/test/DebugInfo/MIR/X86/regcoalescing-clears-dead-dbgvals.mir

  Log Message:
  -----------
  [DebugInfo] Avoid register coalesing unsoundly changing DBG_VALUE locations

This is a re-land of D56151 / r364515 with a completely new implementation.

Once MIR code leaves SSA form and the liveness of a vreg is considered,
DBG_VALUE insts are able to refer to non-live vregs, because their
debug-uses do not contribute to liveness. This non-liveness becomes
problematic for optimizations like register coalescing, as they can't
``see'' the debug uses in the liveness analyses.

As a result registers get coalesced regardless of debug uses, and that can
lead to invalid variable locations containing unexpected values. In the
added test case, the first vreg operand of ADD32rr is merged with various
copies of the vreg (great for performance), but a DBG_VALUE of the
unmodified operand is blindly updated to the modified operand. This changes
what value the variable will appear to have in a debugger.

Fix this by changing any DBG_VALUE whose operand will be resurrected by
register coalescing to be a $noreg DBG_VALUE, i.e. give the variable no
location. This is an overapproximation as some coalesced locations are safe
(others are not) -- an extra domination analysis would be required to work
out which, and it would be better if we just don't generate non-live
DBG_VALUEs.

Differential Revision: https://reviews.llvm.org/D64630