This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo][InstrRef] Add unit tests for transfer-function building
ClosedPublic

Authored by jmorse on Oct 18 2021, 8:46 AM.

Details

Summary

This patch adds some unit tests for the machine-location transfer-function building parts of InstrRefBasedLDV: i.e., test that if we feed some MIR into the transfer-function building code, does it create the correct transfer function.

There are a number of minor defects that get corrected in the process:

  • The unit test was selecting the x86 (i.e. 32 bit) backend rather than x86_64's 64 bit backend,
  • COPY instructions weren't actually having their subregister values correctly represented in the transfer function. Subregisters were being defined by the COPY, rather than taking the value in the source register.
  • All call instructions were clobbering the stack pointer: a recent patch that fiddled with this accidentally inverted the logic. Actually, they were at risk of being clobbered, if an SP subregister was clobbered.

I'll drop inline comments in explaining the different parts.

Otherwise, cosmetically, I've replaced a "getNumAtPos" method with "readMLoc". This is more consistent with the other helper functions for, for example, setting the values in machine locations.

Diff Detail

Event Timeline

jmorse created this revision.Oct 18 2021, 8:46 AM
jmorse requested review of this revision.Oct 18 2021, 8:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 18 2021, 8:46 AM
jmorse added inline comments.Oct 18 2021, 8:52 AM
llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
1111–1114

a) the comment here was wrong, but b) it's important that DBG_PHI instructions are interpreted when building the machine-value transfer function. If there are register operands of DBG_PHIs, they and their subregisters should be tracked. We risk building in some assumption that they're not tracked if we don't do it immediately.

(In the past I've allocated some vectors for "all the registers", then found the number of registers being tracked changed later).

1253–1259

The old implementation of this calculated a new value number for the copy-destinations subregisters, this now reads the source subregister.

jmorse edited the summary of this revision. (Show Details)Oct 18 2021, 8:53 AM
jmorse updated this revision to Diff 380889.Oct 20 2021, 3:56 AM

Squelch some clang-format complaints; I'm not re-formatting the MIR blocks though, clang-format can't know that the contents of the strings needs to be formatted in a readable way.

I've also fiddled with the "COPY" implementation too: super-registers of the destination weren't being def'd, so

$rax = MOV64ri 0
$eax = COPY $ebx

Would be interpreted as $rax still having the value from the MOV, which isn't true. Now all aliases are def'd, and new values copied across for any subregister that's part of the copy. I've also added a further unit test line for that.

jmorse updated this revision to Diff 380892.Oct 20 2021, 4:04 AM

This revision restores a condition/block I deleted from transferDebugPHI: the unit tests weren't observing transferDebugPHI doing anything, which I figured was a bug. However, it was actually because the unit tests were adding the variable-value-tracker / VTracker to InstrRefBasedLDV, making it think it was in a different phase of analysis.

This revision was not accepted when it landed; it landed in state Needs Review.Oct 22 2021, 10:29 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.

Hi, this patch causes test failures on our bot: https://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan/8154/

Can you please take a look and revert if the fix is non-obvious?

Hi, this patch causes test failures on our bot: https://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan/8154/

Can you please take a look and revert if the fix is non-obvious?

Thanks for the heads up -- I think this is an unfortunate composition between two patches that I landed at the same time, the fix is to initialise a new field in the unit tests. I'll try and get a fix up in the next few hours.

Hi, this patch causes test failures on our bot: https://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan/8154/

Can you please take a look and revert if the fix is non-obvious?

Thanks for the heads up -- I think this is an unfortunate composition between two patches that I landed at the same time, the fix is to initialise a new field in the unit tests. I'll try and get a fix up in the next few hours.

Thank you!