This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Unify location selection logic for values in InstrRefBasedImpl
ClosedPublic

Authored by StephenTozer on Dec 20 2022, 9:00 AM.

Details

Summary

Currently the instruction referencing live debug values has 3 separate places where we iterate over all known locations to find the best machine location for a set of values at a given point in the program. Each of these places has an implementation of this check, and one of them has slightly different logic to the others (TransferTracker::loadInLocs prefers registers to spill slots). This patch moves the check for the "quality" of a machine location into a separate function, which also avoids repeatedly calling some slightly-expensive functions, giving a slight performance improvement in optimized debug builds [0].

[0] http://llvm-compile-time-tracker.com/compare.php?from=2ec98ffbf12163ee4ff9f4e674eba714bce24ec1&to=e5163ffef719cd55f7c9641988bbb64effd23b75&stat=instructions%3Au

Diff Detail

Event Timeline

StephenTozer created this revision.Dec 20 2022, 9:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 20 2022, 9:00 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
StephenTozer requested review of this revision.Dec 20 2022, 9:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 20 2022, 9:00 AM
StephenTozer added inline comments.Dec 20 2022, 9:07 AM
llvm/test/DebugInfo/MIR/X86/live-debug-values-restore.mir
382

Note that this test change is caused by the fact that previously, due to loadInLocs preferring registers to spill slots, both of the expected register DBG_VALUEs would be emitted at the start of the block. Since loadInLocs prefers spill slots as-of this patch, the fragment (0, 32) now starts as a spill slot and gets transferred to a register after the kill near the start of the block. This does not affect the substance of the test, as the important part is checking that the register debug values have the correct fragment information, which they still do.

jmorse accepted this revision.Dec 20 2022, 9:26 AM

Slightly twitchy about there being a zero LocIdx -- I think I tried to suppress there being any default-constructed LocIdxes out there. On the other hand, it comes with a sentinel value attached, so it's no big deal.

LGTM.

llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
1617–1618

Feels like an "isBest" method on the LocationAndQuality class might be the best way of performing the check below?

This revision is now accepted and ready to land.Dec 20 2022, 9:26 AM

Slightly twitchy about there being a zero LocIdx -- I think I tried to suppress there being any default-constructed LocIdxes out there. On the other hand, it comes with a sentinel value attached, so it's no big deal.

In this case the reasoning was that LocIdx is 32 bits that only uses 24 for the location, so the sentinel value can be UINT_MAX; since LocationAndQuality uses just 24 bits for the location, I figured there wasn't any good value that could be assigned to the location bits, while the quality bits already tell us whether the location bits mean anything or not.

Updated for review comments, None -> std::nullopt.

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