search for: realignment

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

...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 correct m...

...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 0x00002b4b1352...

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, Saint Petersburg State University

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, Manta...

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

Hi 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

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,

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

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

...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? If &g...

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

Hi, I'm trying to fix an issue with clang's __force_align_arg_pointer__ attribute. The problem is described here: https://llvm.org/bugs/show_bug.cgi?id=26662 The problem is affecting Wine (https://www.winehq.org/) where we have a function that is an entry-point for the x86 Win32 abi. That function may then call functions in the host's (linux, OS/X, ...) abi. The issue is that the

On Thu, Dec 6, 2012 at 12:33 AM, Karthik Bhat <karthikthecool at gmail.com> wrote: > Hi 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

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chad Rosier" <mcrosier at codeaurora.org>, "Jakob Stoklund Olesen" <jolesen at apple.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, November

On Nov 6, 2007, at 6:07 PM, Dale Johannesen wrote: > > On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: >> $ more testcase.c.t03.generic >> Qux () >> { >> static char C.0[11] = {0}; >> char Bar[11]; >> >> Bar = C.0; >> } >> >> Anyway, it turns out that the gimplifier was generating the correct >> alignment, but it was

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