This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Nullify dangling register DBG_VALUEs
ClosedPublic

Authored by aheejin on Dec 8 2022, 2:43 PM.

Details

Summary

Register-based DBG_VALUE should have been
converted into either local-based or stack-operand-based, so at this
point they don't contain any information.

This CL nullifies them, i.e., turning them info
DBG_VALUE $noreg, $noreg, ..., which makes the variable appear as
"optimized out". It is not safe to simply remove these instruction
because at this point, because the fact that there is a DBG_VALUE here
means the location this variable resides has changed to somewhere else;
we've lost that information where that was.


The below is not really about the CL itself, but a pre-existing bug in
llvm-locstats variable coverage we are going to be affected after this
CL. Feel free to skip if you don't have time.

This CL has an unexpected side effect of increasing variable coverage
reported by llvm-locstats, due to a bug mentioned in
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148139.html.
Currently inlined functions' formal parameters that don't have any
coverage, including those who only have DBG_VALUE $noreg, $noregs
associated with them, don't generate DW_TAG_formal_parameter DIEs, and
they don't get into consideration in llvm-dwarf --statistics and
llvm-locstats. This is a known bug mentioned in
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148139.html. For
example, this is a snippet of llvm-dwarfdump output of wc, where
isword is inlined into another function. isword has a formal
parameter c, which doesn't have any coverage in this inlined area, so
its DW_TAG_formal_parameter was not generated:

0x0000018d:     DW_TAG_inlined_subroutine
                  DW_AT_abstract_origin  (0x0000012c "isword")
                  DW_AT_low_pc  (0x00000166)
                  DW_AT_high_pc  (0x0000016d)
                  DW_AT_call_file  ("/usr/local/google/home/aheejin/test/dwarf-verify/wc/wc.c")
                  DW_AT_call_line  (100)
                  DW_AT_call_column  (0x0a)

But our dangling-register-based formal parameters currently generate
DW_TAG_formal_parameter DIEs, even though they don't have any
meaningful coverage, and this happened to generate correct statistics,
because it correctly sees this c doesn't have any coverage in this
inlined area. So our current llvm-dwarfdump (before this CL) is like:

0x0000018d:     DW_TAG_inlined_subroutine
                  DW_AT_abstract_origin  (0x0000012c "isword")
                  DW_AT_low_pc  (0x00000166)
                  DW_AT_high_pc  (0x0000016d)
                  DW_AT_call_file  ("/usr/local/google/home/aheejin/test/dwarf-verify/wc/wc.c")
                  DW_AT_call_line  (100)
                  DW_AT_call_column  (0x0a)

0x0000019a:       DW_TAG_formal_parameter
                    DW_AT_abstract_origin  (0x00000134 "c")

Note that this DW_TAG_formal_parameter doesn't have any
DW_AT_location attribute under it, meaning it doesn't have any
coverage.

On the other hand, if the DW_TAG_formal_parameter is not generated,
llvm-dwarfdump --statistics wouldn't even know about the parameter's
existence, and doesn't include it in the coverage computation, making
the overall coverage (incorrectly) go up.

DBG_VALUE $noreg, $noreg used to generate this empty
DW_TAG_formal_parameter, but it changed for consistency in D95617.

It looks this bug in llvm-dwarf --statistics (and llvm-locstats,
which uses llvm-dwarf --statistics) has not been fixed so far. So we
get the coverage that's little incorrectly higher than our actual
coverage. But this bug apparently affects every target in LLVM.

Diff Detail

Event Timeline

aheejin created this revision.Dec 8 2022, 2:43 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 8 2022, 2:43 PM
Herald added subscribers: pmatos, asb, wingo and 5 others. · View Herald Transcript
aheejin requested review of this revision.Dec 8 2022, 2:43 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 8 2022, 2:43 PM
aheejin edited the summary of this revision. (Show Details)Dec 8 2022, 2:54 PM
aheejin edited the summary of this revision. (Show Details)
aheejin edited the summary of this revision. (Show Details)Dec 8 2022, 2:58 PM
aheejin edited the summary of this revision. (Show Details)Dec 8 2022, 3:20 PM
aheejin edited the summary of this revision. (Show Details)
dschuff accepted this revision.Dec 8 2022, 3:53 PM
dschuff added inline comments.
llvm/lib/Target/WebAssembly/WebAssemblyDebugFixup.cpp
68

If we made this function take the MBB as an arg instead of the MF, we could call it at the end of the main for-loop in runOnMachineFunction. This would mean that we would iterate over each MBB right after having previously iterated over it, (instead of making 2 passes over the whole function), and result in improved locality for functions which are larger than the CPU data cache.

This revision is now accepted and ready to land.Dec 8 2022, 3:53 PM
aheejin updated this revision to Diff 481690.Dec 9 2022, 10:53 AM
aheejin marked an inline comment as done.

Make nullifyDanglingDebugValues run on MBBs

This revision was landed with ongoing or failed builds.Dec 9 2022, 10:59 AM
This revision was automatically updated to reflect the committed changes.