[LLVMdev] Interaction of stacksave/restore and stack spills

[Keno Fischer]

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>