similar to: [LLVMdev] x86 Frame Pointer with AVX

> In trunk, the frame pointer is always set up when an AVX register is used in > a function. This is done in case 32-byte spill code is later introduced into > the function and hence dynamic stack realignment is needed. Needless to say, > it's a big hammer. This regression seems particularly painful in > small-to-medium sized routines that are called frequently in some codes.

On Mon, Oct 22, 2012 at 5:49 PM, Eric Christopher <echristo at gmail.com>wrote: > > In trunk, the frame pointer is always set up when an AVX register is > used in > > a function. This is done in case 32-byte spill code is later introduced > into > > the function and hence dynamic stack realignment is needed. Needless to > say, > > it's a big hammer. This

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

This email did not appear to go through to the list. Resending... On Tue, Oct 23, 2012 at 11:43 AM, Cameron McInally <cameron.mcinally at nyu.edu > wrote: > On Mon, Oct 22, 2012 at 5:49 PM, Eric Christopher <echristo at gmail.com>wrote: > >> > In trunk, the frame pointer is always set up when an AVX register is >> used in >> > a function. This is done in

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 >

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 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 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

Eric Christopher <echristo at gmail.com> writes: >> Is this issue already known? Is there a plan to fix this regression? If not, >> does anyone have a suggestion on the best way to remedy this issue? >> > > You'd need to change the default stack alignment of the platform to > deal with it effectively. That's not possible since such code will have to

> 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

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

Ah, thanks. That seems easy enough. Sorry to be pedantic, but does that snippet also handle cases where the frame pointer, %rbp, needs to be 32-byte aligned when dynamic allocas are present? I've looked at the ABI, but I don't see any guarantees about 32-byte frame alignment for AVX. That can be trouble when spill slots are based off of the frame pointer, not the stack pointer. Please

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,

> Yes, I believe that this is happening if any AVX register is used in a > function; an AVX variable does not necessarily need to be placed on the > stack. > > Maybe I am misunderstanding this piece of code though... > >> // Be over-conservative: scan over all vreg defs and find whether >> vector >> // registers are used. If yes, there is a possibility

----- Original Message ----- > From: "Philip Reames via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, August 28, 2015 6:21:00 PM > Subject: Re: [llvm-dev] Aligned vector spills and variably sized stack frames > > On 08/28/2015 04:00 PM, Philip Reames via llvm-dev wrote: > > I've run

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

On 08/31/2015 03:59 PM, Matthias Braun wrote: > Looks to me like the alignment is specified in tablegen. From Target.td: > > class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, > dag regList, RegAltNameIndex idx = NoRegAltName> > > X86RegisterInfo.td: > > def VR256 : RegisterClass<"X86", [v32i8,

Hey guys, Are spills/reloads of AVX registers using aligned stores/loads? I can't seem to find the code that aligns the stack slots to 32-bytes. Could someone point me in the right direction? Thanks, Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110825/b5724dec/attachment.html>

Two responses inline... My current thinking is that an emergency spill slot could be set aside to > hold the original, ABI conforming, frame pointer. Not an ideal solution, > but in my situation where I must cover any code a user throws at me, > breaking the ABI and playing with the stack is preferred. > > Ah, this is not a good idea. I examined this a while back. The issue is that