This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo][InstrRef] Prefer stack locations for variables over restored registers
ClosedPublic

Authored by jmorse on Mar 1 2022, 7:45 AM.

Details

Summary

This patch adjusts what location is picked for a known variable value -- preferring to leave locations on the stack, even when a value is re-loaded into a register. The benefit is reduced location list entropy, on a clang-3.4 build I found that .debug_loclists reduces in size by 6%, from 29Mb down to 27Mb. The kind of change is demonstrated in the modifications to the spill-nospill.ll test below.

There's a slight risk from the fact that we don't terminate stack variable location at the end of the function, when the stack pointer gets modified a lot during frame destruction. The policy we follow right now [0] is that we expect consumers to know stack locations aren't valid outside the function body. Doing this more often increases the damage if a consumer doesn't have the same expectations. CC @dblaikie , who had an opinion on this last time it came up.

Testing: a few tests need the stack slot to be written to explicitly, to force LiveDebugValues into restoring the variable location to a register. I've added an explicit test for the desired behaviour in livedebugvalues_recover_clobbers.mir .

[0] https://github.com/llvm/llvm-project/blob/843d1eda18c3a7a700fe0858748e175727498d21/llvm/lib/CodeGen/AsmPrinter/DbgEntityHistoryCalculator.cpp#L502

Diff Detail

Event Timeline

jmorse created this revision.Mar 1 2022, 7:45 AM
jmorse requested review of this revision.Mar 1 2022, 7:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2022, 7:45 AM
jmorse updated this revision to Diff 412105.Mar 1 2022, 7:45 AM

(Remembering to upload the modified tests this time)

CC @dblaikie , who had an opinion on this last time it came up.

Got a link to the previous discussion/context?

jmorse added a comment.Mar 1 2022, 3:15 PM

A sample of things are D63083, https://bugs.llvm.org/show_bug.cgi?id=40188#c8 , D61940. Although looking back, they all appear to be about not making complicated location-list entries in the prologue, rather than the epilogue.

Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2022, 3:15 PM

A sample of things are D63083, https://bugs.llvm.org/show_bug.cgi?id=40188#c8 , D61940. Although looking back, they all appear to be about not making complicated location-list entries in the prologue, rather than the epilogue.

Doing it in either place seems wasteful to me. The broad logic is: At -O0 we manage to succeed by using a stack-only location, which seems to imply that the consumers don't try to use that location in the prologue or epilogue (since the stack would be wrong in parts of those regions). So when we do more fine-grained locations, I think the same logic should apply and we shouldn't try to be accurate in those areas - and choose whatever representation is easy to generate and/or dense/efficient to encode. Does that seem reasonable/make sense?

FWIW the change LGTM mechanically and I think it sounds reasonable (/good).

This revision was not accepted when it landed; it landed in state Needs Review.Mar 17 2022, 7:26 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.