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

[Alexey Samsonov]

On Thu, Sep 18, 2014 at 2:02 AM, Frederic Riss <friss at apple.com> wrote:

> >>! 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 see the following note by Jakub in that email thread: "<....> As Tim
pointed out, some calling conventions do actually modify the stack pointer.
But even when they don't, it is normal to have instructions around a call
that do modify the stack pointer to set up a call frame.  The PEI pass
knows where to find stack variables even when the stack pointer is moving,
and it seems to me that debug value tracking should do the same. We also
have two stack slot coloring passes that know exactly where stack variables
are live. "

I think that if call instruction is said to clobber %rsp, we should deal
with it and not hack around it. If there are passes which track the
location of local variables, then we can use a similar pass to update
DBG_VALUE instructions in the machine function as needed.


>
> > 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
>
>
>
-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140918/263dbea3/attachment.html>