This patch works around an edge case in win32 environments that could produce false addresses for variable length arrays.
Most of LiveDebugValues (VarLoc and InstrRef) is written with the assumption that register defs of the stack pointer on call instructions should be ignored -- the call instruction certainly alters SP, but the stack is balanced when the call returns [0]. Unfortunately there's a single scenario where this definitely isn't true: on 32-bit Windows, with variable-length arrays, we call a function _chkstk that both probes the stack and alters the stack pointer. With DBG_VALUE based variable locations, this isn't a huge problem: a DBG_VALUE is applied to the stack pointer after the function returns, and is then copied to other registers. However in instruction referencing mode, we need to instrument the instruction defining the value (see next patch): that means the call to _chkstk, which violates the above assumption that calls don't define the stack pointer.
This patch adds an exception: we add a target frame-lowering hook to see whether stack probe functions will modify the stack pointer, store that in an internal flag, and if it's true then scan CALL instructions to see whether they're such badly-behaved functions. If they are, we recognise them as defining a new stack-pointer value. If we don't do this, then LiveDebugValues will always think "the dynamic allocas address is always whatever the current stack pointer is", which is going to produce false locations if more than one dynamic alloca is used.
The added test exercises this behaviour: two calls to _chkstk should be considered as producing two different values.
[0] This isn't true of stdcall, but I think we have existing difficulties with that anyway.
nit: does- > do