[PATCH] D70676: [DebugInfo] Don't repeatedly created undef DBG_VALUEs during machine-sinking

[Jeremy Morse via Phabricator via llvm-commits]

jmorse created this revision.
jmorse added reviewers: aprantl, vsk, bjope.
Herald added subscribers: llvm-commits, mgrang, hiraditya.
Herald added a project: LLVM.
jmorse added a parent revision: D70672: [DebugInfo] Don't sink DBG_VALUEs past other DBG_VALUEs of the same variable location.

This patch addresses a performance regression reported in PR43855 [0] that appeared as a result of D58386 <https://reviews.llvm.org/D58386> / rGf5e1b718a6 <https://reviews.llvm.org/rGf5e1b718a675a4449b71423f04d38e1e93045105>. To recap: the MachineSink pass used to rely on DBG_VALUE insts always following the instruction that defines the corresponding VReg. D58386 <https://reviews.llvm.org/D58386> collected all debug users as we walked through a block so that non-adjacent DBG_VALUEs could be sunk too.

It turns out that MachineSink will (often) move instructions to the first block that post-dominates the current block, and then try to sink further. This means if we have a lot of conditionals:

  foo = bar + baz;
  if (a)
    b++;
  if (c)          // <---- here
    d++;
  someuseof(foo);

When the computation of "foo" sinks to the bottom of the code, an extra spurious DBG_VALUE $noreg would be placed at the marker. Multiply this a few times, and in [0] there are some functions where an extra 25% DBG_VALUEs appear, all $noreg. This seemingly produced some pathological behaviour elsewhere.

To fix this, rather than immediately sinking DBG_VALUEs, they get recorded into a pass structure. When sinking is complete and instructions won't be sunk any further, new DBG_VALUEs are added, avoiding lots of intermediate DBG_VALUE $noregs being created.

[0] https://bugs.llvm.org/show_bug.cgi?id=43855


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D70676

Files:
  llvm/lib/CodeGen/MachineSink.cpp
  llvm/test/DebugInfo/MIR/X86/machinesink.mir

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D70676.230916.patch
Type: text/x-patch
Size: 8718 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20191125/6e688ed5/attachment.bin>