[llvm-dev] RFC: New IR attribute incoming-stack-align

[Reid Kleckner via llvm-dev]

LLVM managed to survive the 16 byte stack alignment apocalypse on 32-bit
Linux without adding concepts of incoming and outgoing stack alignment, so
I'm hesitant to go back and this extra complexity now.

If we're willing to tolerate the extra complexity of having yet another way
to fiddle with stack alignment, then I agree separating the concepts of
incoming and outgoing SP alignment is the way to go.

On Mon, Mar 14, 2016 at 6:41 AM, Huw Davies via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> I'm trying to fix an issue with clang's __force_align_arg_pointer__
> attribute.  The problem is described here:
> https://llvm.org/bugs/show_bug.cgi?id=26662
>
> The problem is affecting Wine (https://www.winehq.org/) where we have
> a function that is an entry-point for the x86 Win32 abi.  That
> function may then call functions in the host's (linux, OS/X, ...) abi.
> The issue is that the Win32 abi guarantees stack alignment of four
> bytes while the host abi is typically sixteen.
>
> This is supposed to be solved by clang's __force_align_arg_pointer__
> attribute.  What this does is to set the IR attribute alignstack = 16.
> While this does correctly realign the stack it does not change the
> assumption about the alignment of the incoming stack - which is still
> assumed to have an alignment of sixteen.  We need a way to signal to
> the stack layout generator that the incoming alignment can only be
> assumed to be four.
>
> In contrast, gcc realigns the stack but also reduces the assumed
> alignment of the incoming stack to four.
>
> To fix this I'm proposing a new IR attribute "incoming-stack-align"
> that would be set by clang in addition to the alignstack attribute.
> I'm attaching patches to llvm and clang that implement this.  The
> patches are most certainly not correct, but I'd appreciate any
> feedback about how to fix this.
>
> Many thanks,
> Huw.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20160314/71703615/attachment.html>