This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo][InstrRef][NFC] Free resources at an earlier stage, to avoid double accounting
ClosedPublic

Authored by jmorse on Jan 28 2022, 4:38 AM.

Details

Summary

This patch releases some memory from InstrRefBasedLDV earlier that it would otherwise. The underlying problem is:

  • We store a big table of "live in values for each block",
  • We translate that into DBG_VALUE instructions in each block,

And both exist in memory at the same time, which needlessly doubles that information. The most of what this patch does is: as we progressively translate live-in information into DBG_VALUEs, we free the variable-value / machine-value tracking information as we go, which significantly reduces peak memory.

Rolled into this patch too: once we've build the per-block-live-in information, call "clear" on the collection of VLocTracker objects. These store all the variable assignments that happen in a block, there's no need to keep that around once we've made use of them. Doing so exposes another flaw: it seems we were spuriously collecting all variable assignments for a second time, into the final blocks assignment records. Stop this by setting the "VTracker" field of InstrRefBasedLDV to null, and in a couple of locations fix the condition for recording some information.

As a final twiddle, change a DenseMap into a SmallDenseMap to avoid what might be an un-necessary initial allocation.

Diff Detail

Event Timeline

jmorse created this revision.Jan 28 2022, 4:38 AM
jmorse requested review of this revision.Jan 28 2022, 4:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 28 2022, 4:38 AM

nit in commit message:

This patch releases some memory from InstrRefBasedLDV earlier that it would otherwise. The underlying problem is:

"earlier that it would" -> "earlier than it would"

I have a couple of questions but SGTM.

llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
1032

When does this change come into effect (i.e., what stage of the algorithm/pass does this make a difference)?

2830

VTracker never owns what it's pointing to then, unlike TTracker and MTracker?

2853–2854

Is it worth setting to nullptr too, like you've done elsewhere?

3094

Having the clean-up moved up from the confluence into different codepaths makes me a little nervous (for future refactors etc). I'm not sure what else you can do though, just thought I'd mention it in case I'm missing an obvious alternative. I guess one option is to set the ptrs to nullptr after deleting on the other path, and keep the old delete loop lower down in this function (double-deleting in the common case), but I can see why you'd rather not.

dblaikie added inline comments.
llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
2853–2854

Any chance MInLocs/MOutLocs to a better memory management scheme? Looks like at least std::unique_ptr<std::unique_ptr<ValueIDNum[]>[]> would model the ownership here?

jmorse added inline comments.Jan 31 2022, 9:31 AM
llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
1032

Before this patch, VTracker being non-null implied it was the variable-assignments or install-transfers stage. That isn't true any more, hence using this changed condition to detect either of those stages.

(An actual enum would make this all better!)

2830

That's right; there are multiple of the former to contain per-block assignment data. Wheras the latter two are rinsed-and-reused per block.

2853–2854

True about nullptr; for std::unqiue_ptr that ownership model works too, I'll give it a whirl on the compile-time-tracker first. (I imagine there's no overhead, but I'm getting into the habit now).

3094

Yeah, it might be better to fold the depth-first function in the child patch straight into ExtendRanges, with appropriate function stuff. Sadly, as everything gets optimised heavily, we're going to end up jumping through weird hoops even more often ._.

jmorse updated this revision to Diff 405210.Feb 2 2022, 4:11 AM

Will land on the back of Orlando's SGTM; shifting to unique_ptr sounds good and doesn't appear to have a performance impact, I've spun that into D118774.

This revision was not accepted when it landed; it landed in state Needs Review.Feb 2 2022, 4:58 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.