[llvm-dev] Unaligned Stack Pointer

[Przemyslaw Ossowski via llvm-dev]

Thank you for all responses!



Read zone is in fact a very interesting solution.

But on architectures which don’t support red zones and in case leaf
function eventually modifies stack pointer, why not modify it always
according to alignment?

If for example SP is aligned to 8 bytes and the leaf function wants to
store on stack just one ‘char’ (1-byte), what is the difference between
decreasing SP by 1 instead of 8?

In such case we know that the stack will not grow-down any more (except
interrupt/exception handlers), so in fact we are saving just 7-bytes, which
eventually will not be used.

Is it really worth not aligning the stack pointer just for such case? …
additionally having to manage with unaligned stack pointer in interrupts
handlers…



Or maybe there are other scenarios where unaligned pointers might be used
and brings benefits?



Przemek

On Fri, Sep 18, 2020 at 12:47 AM Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Thu, Sep 17, 2020 at 11:17:03AM -0400, David Jones via llvm-dev wrote:
> > SPARC is a good example. If an interrupt occurs, the OS must flush all
> > register windows out to the user stack.  This requires that the stack
> > pointer be aligned.  Since you have no control over when an interrupt can
> > occur. you must maintain alignment at all times.
>
> The kernel will realign the stack pointer as appropiate for signal
> handlers, so that argument doesn't really work. Interrupt and exception
> handlers normally have their own stacks, so the problem doesn't apply to
> them.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200918/c38c55c3/attachment.html>