search for: realign

...lly defined? I don't seem them appearing in the X86RegisterInfo.td files as I would naively expect. The background for my question is that I'm looking into adding a function attribute which uses unaligned loads and stores for register spilling on x86 to avoid the need for dynamic frame realignment. (see the previous thread "Aligned vector spills and variably sized stack frames") The key difference w.r.t. to the existing "no-realign-stack" attribute is that situations which *require* a stack realignment will generate a fatal_error rather than silently miscompilin...

...his GSoC project that I would like to mentor and I discussed also with Andrei. A good part of our GSoC project is indeed related to this Connex back end that it's not yet part of the LLVM source repository - an important thing proposed in the project is that we plan to perform efficient realignment for this Connex vector processor. I looked a bit in LLVM and I see that support for realignment of misaligned vector memory accesses is not implemented in the LoopVectorize pass (see lib/Transforms/Vectorize/LoadStoreVectorizer.cpp) nor in any back end (folder lib/Target). Please corre...

...on a 16 byte boundary. In other words, the value (%rsp - 8) is always a multiple of 16 when control is transferred to the function entry point. The stack pointer, %rsp, always points to the end of the latest allocated stack frame. << The libc itself assumes it in that way, and does no stack realignment. You can look for example at snprintf disassembly, that dumps SSE registers on the stack: 0x00002b4b13522b60 <snprintf+0>: sub $0xd8,%rsp 0x00002b4b13522b67 <snprintf+7>: mov %rcx,0x38(%rsp) 0x00002b4b13522b6c <snprintf+12>: movzbl %al,%ecx 0x00002b4b...

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 best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Sain...

Hello, Everyone. I've just checked code for dynamic stack realignment. This is needed on targets, where ABI-defined stack alignment is not so big (e.g. x86-32/linux, mingw32, cygwin, etc), but some stack objects (e.g. vectors) will require higher alignment. I think, I checked all 'hard' situations and code also survived llvm-gcc bootstrap, Qt, Mozilla, M...

...er words, the value (%rsp - 8) is always a multiple of 16 when control is > transferred to the function entry point. The stack pointer, %rsp, > always points to > the end of the latest allocated stack frame. > << > > The libc itself assumes it in that way, and does no stack realignment. 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. Andrew.

...I don't seem them appearing in the X86RegisterInfo.td files as I would naively expect. >> >> The background for my question is that I'm looking into adding a function attribute which uses unaligned loads and stores for register spilling on x86 to avoid the need for dynamic frame realignment. (see the previous thread "Aligned vector spills and variably sized stack frames") The key difference w.r.t. to the existing "no-realign-stack" attribute is that situations which *require* a stack realignment will generate a fatal_error rather than silently miscompiling....

...David, I think it might not be exactly PR13303 which might be causing the corruption of struct when accessed through GDB. This seems to be an ABI problem in clang. The problem seems to be that when we have pass by value of struct (having indirect arguments) stack is not aligned properly. I tried realigning the stack for indirect arguments in(TargetInfo.cpp) - ABIArgInfo X86_32ABIInfo::getIndirectResult(QualType Ty, bool ByVal) ..... if (StackAlign == 0) return ABIArgInfo::getIndirect(4, /*ByVal=*/true, /*Realign=*/true); // Do a realign of stack....

...er than the default stack alignemnt (b) dynamic alloca (3) If (a) is present and not (b), use the frame pointer to address arguments and the stack pointer to address local variables. If (b) is present and not (a), use the frame pointer to address arguments and local variables. Realign the stack pointer to the largest alignment needed for dynamic alloca. If (a) and (b) are present, adjust the isStatic attribute of all allocas with alignment larger than the default stack alignment. Deal with the rest like the case before. At least for 32bit x86 reserving another...

On my (out-of-tree) target I have 16 128-bit registers. Unaligned load/store are illegal. (must 16-bytes aligned) 8 of those registers are defined as callee-saved and 8 caller-saved. The default stack size is 4 bytes. The target implements dynamic stack realign to make sure the stack will always be aligned correctly when necessary. Yet I am still getting unaligned load/store when running this test case: http://pastie.org/8490604 The problem is in PEI::calculateCalleeSavedRegisters: // We may not be able to satisfy the desired alignment specificat...

...t eliminateFrameIndex() when necessary. I am looking at > > several approaches, but I would like input from anyone who > > has an opinion. > I haven't looked into the patch deep enough yet, but I have at least 2 > questions: > 1. How do all the stuff play with dynamic stack realignment? > 2. It seems, that dwarf information about callee-saved registers is > invalidated by your patch. > This means, that you won't have sane stack traces in the debugger. > Unwinding won't also work. > Have you tried to compile some C++ code, which uses EH? Integrating sh...

...12 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 regression seems particularly painful in > > small-to-medium sized routines that are called frequently in some codes. > > > > > > Is this issue already known? Is there a plan to fix this regression? I...

Hello, I am applying for Google Summer of Code with a project related to LLVM and Connex SIMD processor and I would appreciate some feedback on the proposal. The proposal can be found here: https://docs.google.com/document/d/1pBRbW8pU9GV8zWCJQrILhynNEBpGXJKtev1j7ekXfqs/edit?usp=sharing Thank you, Andrei Popa

...native 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 necessary, for example due to spill of vector register. So, we'll need to decide very late whether we'll need realignment or not. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello, David. > After hacking around in the CBE output I managed to compile it with > gcc, only to discover that gcc 4.1.2 has the SAME bug LLVM does with > respect to alignment. Automatic stack realignment was atted to X86 backend ~3 months ago. Everything should work with LLVM. If not - please fill out a PR. AFAIR, automatic stack realignment still does not land into gcc mainline (it's on maybe 8th or 9th iteration or so). > I don't see a way to run opt directly with bugpoint. It...

...S/X, ...) abi. The issue is that the Win32 abi guarantees stack alignment of four bytes while the host abi is typically sixteen. This is supposed to be solved by clang's __force_align_arg_pointer__ attribute. What this does is to set the IR attribute alignstack = 16. While this does correctly realign the stack it does not change the assumption about the alignment of the incoming stack - which is still assumed to have an alignment of sixteen. We need a way to signal to the stack layout generator that the incoming alignment can only be assumed to be four. In contrast, gcc realigns the stack but...

...be exactly PR13303 which might be causing the > corruption of struct when accessed through GDB. > This seems to be an ABI problem in clang. > The problem seems to be that when we have pass by value of struct > (having indirect arguments) stack is not aligned properly. > > I tried realigning the stack for indirect arguments in(TargetInfo.cpp) - > > ABIArgInfo X86_32ABIInfo::getIndirectResult(QualType Ty, bool ByVal) > > ..... > if (StackAlign == 0) > return ABIArgInfo::getIndirect(4, /*ByVal=*/true, > /*Realign=*/true)...

...ned load/store are illegal. (must 16-bytes aligned) > > > > > > > > > > > > 8 of those registers are defined as callee-saved and 8 > > > caller-saved. > > > The default stack size is 4 bytes. > > > The target implements dynamic stack realign to make sure the > > > stack > > > will always be aligned correctly when necessary. > > > > > > > > > Yet I am still getting unaligned load/store when running this > > > test > > > case: http://pastie.org/8490604 > > > >...

...if (DECL_INITIAL (decl) != 0 && DECL_INITIAL (decl) != >> error_mark_node) >> align = CONSTANT_ALIGNMENT (DECL_INITIAL (decl), align); >> #endif >> } > > Not sure I'm getting it, is this Bar itself or the constructed C.0 > that's getting realigned? > It's C.0 that's getting realigned. -bw

...t; > > Option 3 - Add an option in the x86 backend to not require aligned > > spill slots for AVX2 registers. In particular, the VMOVUPS > > instruction can be used to spill vector registers into an 8 or 16 > > byte > > aligned spill slot and not require dynamic frame realignment. This > > seems like it might be useful in other context as well, but I can't > > name any at the moment. > > > > One thing that occurs to me is that many spills are down rare > > paths. > > Maybe it would make sense to only do dynamic alignment for hot &...