<div dir="ltr">No, stackrestore shouldn't affect any SSA values, except those produced by dynamic alloca instructions executed after the stacksave call that produced the value used for restoration. If not, we have bugs.<div><br></div><div>If LLVM sees dynamic stack adjustments (dynamic alloca or SP adjusting inline asm), it will arrange to address all stack objects from the frame pointer. If the frame requires stack realignment, then it will allocate a *third* register that it names the "base" pointer register (hardcoded to esi or rbx on x86 because they are callee-saved), and address stack objects and spill slots from that.</div><div><br></div><div>Our scheme could break down if you have some stack adjustment that LLVM doesn't know about, but that's a problem even without stacksave/restore.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 11, 2015 at 9:28 AM, Keno Fischer <span dir="ltr"><<a href="mailto:kfischer@college.harvard.edu" target="_blank">kfischer@college.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi everyone,</div><div><br></div>I'm curious about the constraints that come with the usage of llvm.stacksave/llvm.stackrestore. Specifically I was wondering what the contract of their usage was with respect to SSA variables defined after llvm.stacksave. It seems to me that they could get spilled to a stack slot, which I'm concerned stackrestore might mess up. Is this a valid concern?<div><br></div><div>Thanks,<br>Keno</div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>