search for: stackalignment

I thought of another work around. The FSF gcc driver can implicitly add -no_compact_unwind to the link line. This tells the linker to not produce compact unwind information from the dwarf unwind info in .o files. Then at runtime the darwin unwinder will fallback and use the slow dwarf unwind info. -Nick On Sep 18, 2009, at 2:27 PM, Nick Kledzik wrote: > I dug into this. Based on

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

Hi all, I'm learning the PTX backend and confused by the following problem. In the constructor of PTXFrameLowering, StackAlignment and LocalAreaOffset are assigned 2 and -2, respectively. Since PTX has neither stack frame nor stack pointer, why StackAlignment and LocalAreaOffset are needed and where does 2 and -2 come from? Any explanation is appreciated. Thank you in advance! Yours Sincerely, Lei Mou -------------- next part...

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Francois Pichet" <pichet2000 at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 18, 2013 2:45:53 PM > Subject: Re: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > ----- Original

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 18, 2013 2:26:30 PM > Subject: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > > > On my (out-of-tree) target I have 16 128-bit registers. >

BTW I managed to get around this problem by flagging all the 128-bit registers as caller saved only. On my system, vector registers are more likely to be used on leaf functions anyway. On Thu, Nov 21, 2013 at 3:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Hal Finkel" <hfinkel at anl.gov> > > To: "Francois

On Mon, Apr 16, 2012 at 3:48 AM, Lei Mou <lei.mou.uu at gmail.com> wrote: > Hi all, > > I'm learning the PTX backend and confused by the following problem. In the > constructor of PTXFrameLowering, StackAlignment and LocalAreaOffset are > assigned 2 and -2, respectively. Since PTX has neither stack frame nor > stack pointer, why StackAlignment and LocalAreaOffset are needed and where > does 2 and -2 come from? Any explanation is appreciated. Thank you in > advance! > There's really no go...

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

...tains invalid align information, this optimization breaks and it incorrectly optimizes add by 4 into xor by 4, when the object is (in reality) aligned by 4, not by 8(which MFI thinks about it's alignment) Two solutions come into my mind: 1) changiing the SelectionDAGBuilder to use std::min(StackAlignment, PreferredAlignment) instead of PreferredAlignment. This might require asserting (StackAlignment <= ABI alignment). 2) changing the SelectionAGBuilder to use ABI alignment instead of the preferred alignment for the stack objects. The affected code lines are around 4820, and 5694 of SelectionD...

On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote: > I thought of another work around. The FSF gcc driver can implicitly > add -no_compact_unwind to the link line. This tells the linker to not > produce compact unwind information from the dwarf unwind info in .o > files. Then at runtime the darwin unwinder will fallback and use the > slow dwarf unwind info.

Hi everyone, For those who like to play with experimental stuff, I've got something new to test. If you compile with --enable-vorbis-psy , Speex uses a variant of the Vorbis psycho-acoustic model to shape the coding noise. So far, I've obtained a slight increase in quality, but I'm interested in feedback from others. This still needs a lot of tuning and has received only a minimal

I'm using wine in combination with pylotro for playing Lotro with Arch Linux. Since about a month the game start is blocked with the message: err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xf75822fe wine client error:9: write: Ung??ltiger Dateideskriptor (bad file descriptor) Today I was trying again to manage that problem. When I keep the crashed game open and start

...e. bool Is64Bit; Index: lib/Target/X86/X86Subtarget.cpp =================================================================== --- lib/Target/X86/X86Subtarget.cpp (revision 301500) +++ lib/Target/X86/X86Subtarget.cpp (working copy) @@ -312,6 +312,7 @@ SlowLEA = false; SlowIncDec = false; stackAlignment = 4; + SaveArgs = false; // FIXME: this is a known good value for Yonah. How about others? MaxInlineSizeThreshold = 128; UseSoftFloat = false; Index: lib/Target/X86/X86Subtarget.h =================================================================== --- lib/Target/X86/X86Subtarget.h (revisi...

> When enabling and compiling this with mingw on Win32, my debugger > complains about heap overruns when calling speex_encoder_destroy(). This > could be a mingw issue though, as I also found a stackalignment bug which > prevents me from _USING_SSE (apparantly -mpreferred-stack-size is just > "prefered" and therefore ignored... *Sigh*). Just so I understand, the debugger complains, but the code still runs? What's the message? > But, before that point, there seems to be.. well....

...ssibility that vector register > // will be spilled and thus require dynamic stack realignment. > for (unsigned i = 0, e = RI.getNumVirtRegs(); i != e; ++i) { > unsigned Reg = TargetRegisterInfo::index2VirtReg(i); > if (RI.getRegClass(Reg)->getAlignment() > StackAlignment) { > FuncInfo->setForceFramePointer(true); // <= Forces Frame Pointer for any AVX reg use!!! > return true; > } > } Just to be pedantic, at one time this did work properly for AVX without adding the unnecessary frame pointer. It is a proper regressio...

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

+nlewycky On Mon, Nov 17, 2014 at 9:36 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch > wrote: > Hi Kostya, > > On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov < > vova.kuznetsov at epfl.ch> wrote: > > Do you think moving the pass to lib/Transform/Instrumentation but > > scheduling it during code generation would make sense ? If so, we'll >

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

...;> register >> // will be spilled and thus require dynamic stack realignment. >> for (unsigned i = 0, e = RI.getNumVirtRegs(); i != e; ++i) { >> unsigned Reg = TargetRegisterInfo::index2VirtReg(i); >> if (RI.getRegClass(Reg)->getAlignment() > StackAlignment) { >> FuncInfo->setForceFramePointer(true); // <= Forces Frame Pointer >> for any AVX reg use!!! >> return true; >> } >> } > > Just to be pedantic, at one time this did work properly for AVX without > adding the unnecessary...

...ng and has > received only a minimal amount of testing, so don't use it for something > important. When enabling and compiling this with mingw on Win32, my debugger complains about heap overruns when calling speex_encoder_destroy(). This could be a mingw issue though, as I also found a stackalignment bug which prevents me from _USING_SSE (apparantly -mpreferred-stack-size is just "prefered" and therefore ignored... *Sigh*). But, before that point, there seems to be.. well.. I seem to think it's better, but that could be just because I expect it to be better. If the heap probl...