search for: realignable

Looking around today, it appears that TargetRegisterClass and MCRegisterClass only includes a single alignment. This is documented as being the minimum legal alignment, but it appears to often be greater than this in practice. For instance, on x86 the alignment of %ymm0 is listed as 32, not 1. Does anyone know why this is? Additionally, where are these alignments actually defined? I

Hello, Anton, I'd like to add a small reply regarding this 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

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 function entry point. The stack pointer, %rsp,

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

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 compilation, but please

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

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,

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,

...ent is smaller. Use the // min. Align = std::min(Align, StackAlign); FrameIdx = MFI->CreateStackObject(RC->getSize(), Align, true); This will create unaligned load/store for a callee-saved 128-bit register on the frame slot because StackAlign is 4. Adding a check for stack realignable or putting all the 128-bit registers as caller-save will fix the problem. if (!TFI->isStackRealignable()) <--- new line Align = std::min(Align, StackAlign); Is this a bug or am I missing something? Thanks, Francois Pichet, Octasic. -------------- next part -------------- An...

Hi Anton, Thanks for your questions, that's what I'm looking for. On Thu, Feb 26, 2009 at 5:33 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Hello, John > > > My limited implementation uses a workaround that adjusts the > > generation of prologue code and the frame indices used by > > the target eliminateFrameIndex() when necessary. I am

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

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

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

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

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

...reateStackObject(RC->getSize(), Align, true); > > > > > > > > > This will create unaligned load/store for a callee-saved 128-bit > > > register on the frame slot because StackAlign is 4. > > > > > > > > > Adding a check for stack realignable or putting all the 128-bit > > > registers as caller-save will fix the problem. > > > > > > if (!TFI->isStackRealignable()) <--- new line > > > Align = std::min(Align, StackAlign); > > > > > > Is this a bug or am I missing something? &gt...

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

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