Chuck,> It is dying trying to store a our working vector into one of the LLVM > vectors created on the stack. Despite the align-16 directive on the > alloca instruction, it is not always aligning to a 16-byte boundary.The stack is not necessary 16 bytes aligned on linux/windows. The vector is really sotred aligned relative to %esp, but %esp value is not good. This is known problem (PR1636 / PR1649) and I'm currently working on the solution (actually - stack realignment). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
On 9/28/07, Anton Korobeynikov <asl at math.spbu.ru> wrote:> Chuck, > > > It is dying trying to store a our working vector into one of the LLVM > > vectors created on the stack. Despite the align-16 directive on the > > alloca instruction, it is not always aligning to a 16-byte boundary. > The stack is not necessary 16 bytes aligned on linux/windows.On recent versions of linux (anything in the past 2 years), the stack will be aligned by gcc, the kernel, and glibc, in all the right functions. So unless you misalign it, ...
What is gcc's caller stack alignment assumption on Linux? Unless it's 16 byte or more, the callee will have to dynamically align the stack. Evan On Sep 28, 2007, at 5:49 PM, Daniel Berlin <dberlin at dberlin.org> wrote:> On 9/28/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Chuck, >> >>> It is dying trying to store a our working vector into one of the >>> LLVM >>> vectors created on the stack. Despite the align-16 directive on the >>> alloca instruction, it is not always aligning to a 16-byte boundary. >> The stack is not necessary 16 bytes aligned on linux/windows. > > On recent versions of linux (anything in the past 2 years), the stack > will be aligned by gcc, the kernel, and glibc, in all the right > functions. > > So unless you misalign it, ... > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hello, Daniel.> glibc < 2.4 don't reliably keep stack at 16 bytes through some calls > (qsort, etc), but otherwise, it stays 16 byte aligned.Interesting, but why in this case stuff like 'force_align_arg_pointer' required? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
If you mix with older gcc versions (say 2.95), they will default to a 4 byte aligned stack, not a 16 byte one. See http://gcc.gnu.org/ml/gcc-patches/2006-02/txt00052.txt On 9/30/07, Anton Korobeynikov <asl at math.spbu.ru> wrote:> Hello, Daniel. > > > glibc < 2.4 don't reliably keep stack at 16 bytes through some calls > > (qsort, etc), but otherwise, it stays 16 byte aligned. > Interesting, but why in this case stuff like 'force_align_arg_pointer' > required? > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
You can always ask for > 16 byte stack alignment. :-) Evan On Sep 30, 2007, at 10:47 AM, Anton Korobeynikov wrote:> Hello, Daniel. > >> glibc < 2.4 don't reliably keep stack at 16 bytes through some calls >> (qsort, etc), but otherwise, it stays 16 byte aligned. > Interesting, but why in this case stuff like 'force_align_arg_pointer' > required? > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev