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].
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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. |
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? |
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.
Feels like an "isBest" method on the LocationAndQuality class might be the best way of performing the check below?