<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 18, 2014 at 2:02 AM, Frederic Riss <span dir="ltr"><<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">>>! In D5366#10, @samsonov wrote:<br>
> 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.<br>
<br>
</span>I should have mentioned this is the initial message, but I actually investigated that out a few weeks ago: <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140811/230791.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140811/230791.html</a><br>
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.<br></blockquote><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">I see the following note by Jakub in that email thread: "<....> </span><span style="font-size:13px;font-family:arial,sans-serif">As Tim pointed out, some calling conventions do actually modify the stack pointer. But even when they don't, it is normal </span><span class="" style="font-size:13px;font-family:arial,sans-serif">to</span><span style="font-size:13px;font-family:arial,sans-serif"> have instructions around a call that do modify the stack pointer </span><span class="" style="font-size:13px;font-family:arial,sans-serif">to</span><span style="font-size:13px;font-family:arial,sans-serif"> set up a call frame.  </span><span style="font-size:13px;font-family:arial,sans-serif">The PEI pass knows where </span><span class="" style="font-size:13px;font-family:arial,sans-serif">to</span><span style="font-size:13px;font-family:arial,sans-serif"> find stack variables even when the stack pointer is moving, and it seems </span><span class="" style="font-size:13px;font-family:arial,sans-serif">to</span><span style="font-size:13px;font-family:arial,sans-serif"> 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. "</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">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.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> 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.<br>
<br>
</span>And if we decided to do it on DbgValueHistoryCalculator, the RSP issue would still be there. Every liveness analysis relies on def/kill information.<br>
<br>
<a href="http://reviews.llvm.org/D5366" target="_blank">http://reviews.llvm.org/D5366</a><br>
<br>
<br>
</blockquote></div><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</div></div>