This is an archive of the discontinued LLVM Phabricator instance.

[1/2][LiveDebugVariables] Avoid reduntant DBG_VALUEs after virtregrewrite
AbandonedPublic

Authored by djtodoro on Jun 28 2021, 6:50 AM.

Details

Summary

After the register allocator is done, more precisely, after the Virtual Register Rewriter, we end up having duplicated DBG_VALUEs, since some virtual registers are being rewritten into the same physical register as some of existing DBG_VALUEs. Each DBG_VALUE should indicate (at least before the LiveDebugValues) variables assignment, but it is being clobbered for function parameters during the SelectionDAG since it generates new DBG_VALUEs after COPY instructions, even though the parameter has no assignment. For example, if we had a DBG_VALUE $regX as an entry debug value representing the parameter, and a COPY and after the COPY, DBG_VALUE $virt_reg, and after the virtregrewrite the $virt_reg gets rewritten into $regX, we'd end up having redundant DBG_VALUE.

This breaks the definition of the DBG_VALUE since some analysis passes might be built on top of that premise..., and this patch tries to fix the MIR with the respect to that.

Diff Detail

Event Timeline

djtodoro created this revision.Jun 28 2021, 6:50 AM
djtodoro requested review of this revision.Jun 28 2021, 6:50 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 28 2021, 6:50 AM

This sounds great to me -- suppressing redundant DBG_VALUEs is a good aim. I'm slightly worried about performance however: in D94981 a patch landed to cover a scenario where findInsertLocation was repeatedly stepping back over every debug instruction at the start of a block, effectively becoming quadratic-complexity. Wouldn't looking back over every DBG_VALUE already inserted, when inserting a new one, become quadratic too?

Possibly the solution is to act like D94981, and build a temporary cache of "DBG_VALUEs already inserted at this SlotIdx".

llvm/test/DebugInfo/X86/livedebugvars-avoid-duplicates.ll
4

This is running quite a lot of llc, to then hit a fair specific scenario (DBG_VALUE then frame-setup), which makes me worry that it'll be fragile. Would it be sufficient to just check that there are two DBG_VALUEs in the output MIR, and that's it?

(Also, hard-coded metadata numbers)

This sounds great to me -- suppressing redundant DBG_VALUEs is a good aim. I'm slightly worried about performance however: in D94981 a patch landed to cover a scenario where findInsertLocation was repeatedly stepping back over every debug instruction at the start of a block, effectively becoming quadratic-complexity. Wouldn't looking back over every DBG_VALUE already inserted, when inserting a new one, become quadratic too?

Possibly the solution is to act like D94981, and build a temporary cache of "DBG_VALUEs already inserted at this SlotIdx".

Yes... I wanted to get a consensus this is needed, and definitely, I'll need to measure performance impact and optimize it eventually. I think some caching will be appreciated here in order to avoid (potential) performance regression.

llvm/test/DebugInfo/X86/livedebugvars-avoid-duplicates.ll
4

yep, I'll need to fix it

Orlando added inline comments.Jun 28 2021, 8:03 AM
llvm/test/DebugInfo/X86/livedebugvars-avoid-duplicates.ll
4

You could add --implicit-check-not=DBG_VALUE to FileCheck here too to ensure there are no extra DBG_VALUEs?

ormris removed a subscriber: ormris.Jun 29 2021, 10:17 AM
djtodoro abandoned this revision.Jul 1 2021, 6:52 AM

Alternative implemented as D105279.