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
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.
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?
That actually sounds like a bug. It could be in LLVM or in its use, but
it's probably worth chasing down.