Over in D116821, there's a reproducer that stimulates an interesting scenario in InstrRefBasedLDV: with thousands of local variables and asan enabled, the max working set (i.e. maximum number of values live at the same time) is very large, and get forced onto the stack. InstrRefBasedLDV tries to track all those variable locations, allocates some massive tables of values, and can then run out of memory (think ~6k values across 15k blocks -> massive allocations). This is undesirable.
I believe this kind of input is rare, because it's very unlikely that a developer is able to reason about thousands of live, named variables, concurrently while writing their software. Much more likely is that the input is autogenerated, or affected by some kind of instrumentation. In that scenario we should fail gracefully, by ceasing to track stack slots past a certain number: which is what this patch does. That puts an upper bound on the maximum working set that we try to track, and avoids un-necessarily crashing. The downside is that we might un-necessarily drop some variable locations, but the developer is probably happy with something rather than nothing.
This can certainly be improved so that the quality of data tracked degrades gracefully, however this is a starting point that avoids excessive consumption.
In terms of the patch, this adds a cl::opt for max number of stack slots to track, and has the stack-slot-numbering code optionally return None. That then filters through a number of code paths, which can then chose to not track a spill / restore if it touches an untracked spill slot. The added test checks that we drop variable locations that are on the stack, if we set the limit to zero.
nit: developers -> developer's