[LLVMdev] stack alignment (again)

[Dale Johannesen]

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 doesn't occur on the mac, because the stack is always  
> guaranteed to be 16-byte aligned.

Another possibility, which only works if you have control of all the  
code being compiled, is to 16-byte align the stack in main and keep it  
16-byte aligned thereafter.  Different versions of gcc have used this  
method and the method Chris suggests.

Still another is to disable generation of SSE instructions.  -mattr=- 
sse2 should work.  The gcc switch, -mno-sse2, did not work in llvm-gcc  
last time I tried; this is on my list of things to make work, but  
fairly far down.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080330/30934279/attachment.html>