[PATCH] D146744: [WebAssembly] Redesign DebugValueManager

Heejin Ahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 23 10:54:01 PDT 2023


aheejin created this revision.
aheejin added reviewers: dschuff, yurydelendik.
Herald added subscribers: pmatos, asb, wingo, ecnelises, sunfish, hiraditya, jgravelle-google, sbc100.
Herald added a project: All.
aheejin requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

The current `DebugValueManager`, which is mostly usd in `RegStackify`,
simply sinks `DBG_VALUE`s along when a def instruction sinks.
(`RegStackify` only does sinks; it doesn't do hoists.)

But this simple strategy can result in incorrect combinations of
variables' values which would have not been possible in the original
program. In this case, LLVM's policy is to make the value unavailable,
so they will be shown as 'optimized out', rather than showing inaccurate
debug info. Especially, when an instruction sinks, its original
`DBG_VALUE` should be set to undef. This is well illustrated in the
third example in
https://llvm.org/docs/SourceLevelDebugging.html#instruction-scheduling.

This CL rewrites `DebugValueManager` with this principle in mind. When
sinking an instruction, it sinks its eligible `DBG_VALUE`s with it, but
also leaves undef `DBG_VALUE`s in the original place to make those
variables' values undefined.

Also, unlike the current version, we sink only an eligible subset of
`DBG_VALUE`s with a def instruction. See comments in the code for
details.

In case of cloning, because the original def is still there, we don't
set its `DBG_VALUE`s to undef. But we clone only an eligible subset of
`DBG_VALUE`s here as well.

One consequence of this change is that now we do sinking and cloning of
the def instruction itself within the `DebugValueManager`'s `sink` and
`clone` methods. This is necessary because the `DebugValueManager` needs
to know the original def's location before sinking and cloning in order
to scan other interfering `DBG_VALUE`s between the original def and the
insertion point. If we want to separate these two, we need to call
`DebugValueManager`'s `sink` and `clone` methods _before_
sinking/cloning the def instruction, which I don't think is a good
design alternative either, because the user of this class needs to pay
extra attention when using it.

Because this change is fixing the existing inaccuracy of the current
debug info, this reduces the variable info coverage in debug info, but
not by a large margin. In Emscripten core benchmarks compiled with
`-O1`, the coverage goes from 56.6% down to 55.2%, which I doubt will be
a noticeable drop. The compilation time doesn't have any meaningful
difference either with this change.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146744

Files:
  llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.h
  llvm/lib/Target/WebAssembly/WebAssemblyDebugValueManager.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyDebugValueManager.h
  llvm/lib/Target/WebAssembly/WebAssemblyRegStackify.cpp
  llvm/test/DebugInfo/WebAssembly/dbg-value-move-2.ll
  llvm/test/DebugInfo/WebAssembly/dbg-value-move-reg-stackify.mir
  llvm/test/DebugInfo/WebAssembly/dbg-value-reg-stackify.mir

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D146744.507817.patch
Type: text/x-patch
Size: 54825 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230323/66848c19/attachment.bin>


More information about the llvm-commits mailing list