[PATCH] Consider the frame base isn't moving in calculateDbgValueHistory.

[Frederic Riss]

>>! In D5366#10, @samsonov wrote:
> Why is RSP clobbered by the calls in the first place? If $rsp is used to address local variables, then does it mean the generated code actually has to spill $rsp before calling a function and restore $rsp after that? That looks weird.

I should have mentioned this is the initial message, but I actually investigated that out a few weeks ago: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140811/230791.html
The consensus seemed to be that we need to deal with it. From a purely theoretical POV, it is true that a call will write to the stack pointer, thus the annotation isn't wrong. I'm proposing a way to just deal with it.

> I considered adding a liveness analysis here, but it seems that DbgValueHistoryCalculator is a wrong place for this: it's pain to match the propagation of debug variables' locations in the control flow graph with the order the actual basic blocks are emitted in the object file (as this is the order we care about when we generate .debug_loc section). It is doable, but painful and can be pretty slow. Instead, it would be better to somehow reuse/fix LiveDebugVariables pass (which is currently used only by optimized register allocator), and track locations by inserting DBG_VALUEs where necessary.

And if we decided to do it on DbgValueHistoryCalculator, the RSP issue would still be there. Every liveness analysis relies on def/kill information.

http://reviews.llvm.org/D5366