[LLVMdev] stack alignment (again)

[Evan Cheng]

On Mar 30, 2008, at 10:21 AM, Chris Lattner wrote:

> On Mar 28, 2008, at 5:17 PM, Chuck Rose III wrote:
>> I was curious about the state of stack alignment on x86.  I noticed  
>> there are a few bugs outstanding on the issue.  I recently added  
>> some code which had the effect of throwing an extra function  
>> parameter on our stack at runtime, a 4 byte pointer.
>>
>> Esp is now not 16-byte aligned, so instructions like unpcklps xmm1,  
>> dword ptr [eps] cause grief.  My AllocaInstr instructions are told  
>> to be 16 byte aligned, so the addition of a 4-byte parameter  
>> shouldn’t have changed alignment on the objects.
>
> Hi Chuck,
>
> I think the basic problem is that the stack pointer on windows/linux  
> is not guaranteed to be 16 byte aligned.  This means that any use of  
> an instruction which requires 16-byte alignment (e.g. sse stuff) and  
> accesses a frameindex can cause a problem.  The issue is that the  
> frameindex will be marked as needing 16+ byte alignment, but the  
> code generator just won't respect this.
>
> The fix for this is somewhat simple: in Prolog/Epilog Insertion, the  
> PEI pass should notice when frame indices have alignment greater  
> than the guaranteed stack alignment.  When this happens, it should  
> emit code into the prolog to dynamically align the stack (e.g. by  
> emitting 'and esp, -16').

This only works if frame pointer is not being omitted. Otherwise, you  
can't restore to the old stack pointer in the epilogue. So  
X86RegisterInfo::hasFP() must return true for Windows when any of the  
frame slots have alignment greater than the default alignment.

Evan


>
> This doesn't occur on the mac, because the stack is always  
> guaranteed to be 16-byte aligned.
>
> -Chris
> _______________________________________________
> 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/20080330/977bfc9d/attachment.html>