MemLocFragmentFill uses an IntervalMap to track which bits of each variable are stack-homed. Intervals with the same value (same stack location base address) are automatically coalesced by the map. This patch changes the analysis to take advantage of that and insert a new dbg loc after each def if any coalescing took place. This results in some additional redundant defs (we insert a def, then another that by definition shadows the previous one if any coalescing took place) but they're all cleaned up thanks to the previous patch in this stack.
This reduces the total number of fragments created by AssignmentTrackingAnalysis which reduces compile time because LiveDebugValues computes SSA for every fragment it encounters. There's a geomean reduction in instructions retired in a CTMark LTO-O3-g build of 0.3% with these two patches.
One small caveat is that this technique can produce partially overlapping fragments (e.g. slice [0, 32) and slice [16, 64)), which we know LiveDebugVariables doesn't really handle correctly. Used in combination with instruction-referencing this isn't a problem, since LiveDebugVariables is effectively side-stepped in instruction-referencing mode.
I wonder if there's a pathological case where we effectively store a history of defs that we then have to manually clear up, at reasonable expense.
Not really a criticism, everything in compilers has a pathological case, and this is clearly a net positive for compilation overall.