llvm dev - May 2015 - [LLVMdev] Interaction of stacksave/restore and stack spills

Hi everyone,

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?

Thanks,
Keno
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150511/26a63ebc/attachment.html>

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.

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.

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.

On Mon, May 11, 2015 at 9:28 AM, Keno Fischer <kfischer at
college.harvard.edu>
wrote:
> Hi everyone,
>
> 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?
>
> Thanks,
> Keno
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150511/6a53d95e/attachment.html>

Ok, thanks. The reason this came up because Valgrind was yelling at us for
accessing memory below the stack pointer. I suppose that is inevitable?

On Mon, May 11, 2015 at 4:02 PM, Reid Kleckner <rnk at google.com> wrote:
> 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.
>
> 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.
>
> 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.
>
> On Mon, May 11, 2015 at 9:28 AM, Keno Fischer <
> kfischer at college.harvard.edu> wrote:
>
>> Hi everyone,
>>
>> 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?
>>
>> Thanks,
>> Keno
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150511/2afba683/attachment.html>