similar to: [LLVMdev] Stack alignment on X86 AVX seems incorrect

On Fri, Mar 02, 2012 at 11:58:29AM -0500, Cameron McInally wrote: > On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> > wrote: > ... > > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > > confirms that the use of a frame-pointer is optional.

On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: ... > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > confirms that the use of a frame-pointer is optional. > > So, if one doesn't use ENTER in the prologue and uses RSP to access local >

Cameron, Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not normative. See foot note 7 in the same page. Figure 3.4 on page 21 confirms that the use of a frame-pointer is optional. So, if one doesn't use ENTER in the prologue and uses RSP to access local variables, RBP may be used as a calee-saved GPR. -- Evandro Menezes Austin, TX emenezes at

> > At least for 32bit x86 reserving another register as alternative frame > pointer is very heavy. The above would allow normal spill logic to > decide when to keep a reference in register and when not. It also reuses > existing functionality as much as possible. > Hi Joerg, Yes, this was a problem in my implementation also. Empirically, for the chips I work on, reserving the

On Fri, Mar 02, 2012 at 12:18:19AM -0300, Bruno Cardoso Lopes wrote: > Hi Elena, > > On Thu, Mar 1, 2012 at 8:28 PM, Demikhovsky, Elena > <elena.demikhovsky at intel.com> wrote: > > Even if you explicitly specify –stack-alignment=16 the aligned movs are > > still generated. > > > > It is not an issue related to ABI. > > This looks like PR10841,

Joerg, > At least for 32bit x86 reserving another register as alternative frame > pointer is very heavy. The above would allow normal spill logic to > decide when to keep a reference in register and when not. It also reuses > existing functionality as much as possible. It does not seem to be enough. Even is there are *no* allocas in the function the stack realignment might still be

On Mar 1, 2012, at 3:04 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > Aligning the stack to 32 bytes when there are auto AVX vector variables present shouldn't necessarily break the x86-64 ABI, as long as smaller auto variables remain properly aligned. A similar approach

Hi Elena, On Thu, Mar 1, 2012 at 8:28 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Even if you explicitly specify –stack-alignment=16 the aligned movs are > still generated. > > It is not an issue related to ABI. This looks like PR10841, explanation and the way to solve it: http://llvm.org/bugs/show_bug.cgi?id=10841 Cheers, -- Bruno Cardoso Lopes

Even if you explicitly specify –stack-alignment=16 the aligned movs are still generated. It is not an issue related to ABI. See my original mail: ./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm | grep rbp vmovaps -176(%rbp), %ymm14 vmovaps -144(%rbp), %ymm11 vmovaps -240(%rbp), %ymm13 - Elena From: Cameron McInally

Hi Elena, You're correct. LLVM does not align the stack to 32-bytes for AVX and unaligned moves should be used for YMM spills. I wrote some code to align the stack to 32-bytes when AVX spills are present; it does break the x86-64 ABI though. If upstream would be interested in this code, I can arrange with my employer to send a patch to the mailing list. -Cameron On Mar 1, 2012, at 4:09 PM,

On Thu, Mar 1, 2012 at 4:29 PM, Evandro Menezes <emenezes at codeaurora.org>wrote: ... > Aligning the stack to 32 bytes when there are auto AVX vector variables > present shouldn't necessarily break the x86-64 ABI, as long as smaller auto > variables remain properly aligned. A similar approach was taken for i386 > in GCC in order to support SSE vectors. > > Perhaps

./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm | grep rbp vmovaps -176(%rbp), %ymm14 vmovaps -144(%rbp), %ymm11 vmovaps -240(%rbp), %ymm13 vmovaps -208(%rbp), %ymm9 vmovaps -272(%rbp), %ymm7 vmovaps -304(%rbp), %ymm0 vmovaps -112(%rbp), %ymm0 vmovaps -80(%rbp), %ymm1 vmovaps -112(%rbp), %ymm0

When stack is unaligned, LLVM should generate vmovups instead of vmovaps. - Elena -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Joerg Sonnenberger Sent: Thursday, March 01, 2012 20:31 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack alignment on X86 AVX seems incorrect On Thu, Mar 01, 2012 at 06:16:46PM +0000,

On Thu, Mar 01, 2012 at 06:16:46PM +0000, Demikhovsky, Elena wrote: > vmovaps should not access stack if it is not aligned to 32 I'm not completely sure I understand your problem. Are you saying that the generated code assumes 256bit alignment, your default stack alignment is 128bit and LLVM doesn't adjust it automatically? Joerg

Cameron, Aligning the stack to 32 bytes when there are auto AVX vector variables present shouldn't necessarily break the x86-64 ABI, as long as smaller auto variables remain properly aligned. A similar approach was taken for i386 in GCC in order to support SSE vectors. Perhaps you could elaborate where the ABI was violated when your patch is applied. HTH -- Evandro Menezes

On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally <cameron.mcinally at nyu.edu>wrote: > Aligning the stack to 32 bytes when there are auto AVX vector variables >> present shouldn't necessarily break the x86-64 ABI, as long as smaller auto >> variables remain properly aligned. A similar approach was taken for i386 >> in GCC in order to support SSE vectors. >>

Hello, Andrew > That's right.  If you want to be able to call any code produced by gcc, > you have to preserve 16-alignment.  gcc-generated code does not realign > the stack pointer. This was for gcc < 4.4, where stack alignment handling was really messy. stack-realignment branch was merged afair into gcc 4.4 and allows automatic realignment of stack, when necessary. -- With

On Tue, Oct 23, 2012 at 12:56 PM, Eric Christopher <echristo at gmail.com>wrote: > > Thanks for replying so quickly. Would you elaborate on this further? > > > > It seems costly to change the default stack alignment on the platform, > since > > that would require recompiling all of the system and user libraries to > also > > adhere to 32-byte stack

Corrado Zoccolo wrote: > On Linux x86_64, it is different. The x86-64 ABI says > (http://www.x86-64.org/viewvc/trunk/x86-64-ABI/low-level-sys-info.tex?revision=84&content-type=text%2Fplain): > > The end of the input argument area shall be aligned on a 16 byte boundary. > In other words, the value (%rsp - 8) is always a multiple of 16 when control is > transferred to the

> Thanks for replying so quickly. Would you elaborate on this further? > > It seems costly to change the default stack alignment on the platform, since > that would require recompiling all of the system and user libraries to also > adhere to 32-byte stack alignment. Depending on an alignment not specified > by the ABI would also limit our compiler's interoperability with