[LLVMdev] stack alignment (again)
evan.cheng at apple.com
Sun Mar 30 12:16:47 PDT 2008
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.
> This doesn't occur on the mac, because the stack is always
> guaranteed to be 16-byte aligned.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev