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.
When does this change come into effect (i.e., what stage of the algorithm/pass does this make a difference)?