similar to: [LLVMdev] global alignment

On Aug 14, 2012, at 7:31 AM, Baozeng wrote: > Hello all, > I found that the alignment for stack value has no limitation, but for global value, it has a limitation. > > Here is an example: > > #include <stdio.h> > #include <stdlib.h> > > char x[4000] __attribute__((aligned(4096))); > > int > main (int argc, char ** argv) { > char y[4000]

On 8/14/12 12:19 PM, John McCall wrote: > On Aug 14, 2012, at 7:31 AM, Baozeng wrote: >> Hello all, >> I found that the alignment for stack value has no limitation, but for global value, it has a limitation. Baozen, with what version of LLVM did you do the following test? Was it LLVM mainline? >> >> Here is an example: >> >> #include <stdio.h>

Hell all, I am doing some research work on protecting Xen''s data structures. I know there is a direct-map area(about 12M), in which we can get the physical address of the data structure from its virtual address. My question is : are the stack and the heap of Xen both located in this direct-map area? Since I need protect stack and heap data, so it is easy to identify their physical

Hello all, I notice in previous gsocs of LLVM , there is no projects about language bindings for LLVM. Does that mean it has lower priority than other projects? Current python bindings for LLVM in the trunk are far from complemte. So I would like to improve python bindings for LLVM this summer if possible. My work will be based on llvm-py project ( http://code.google.com/p/llvm-py/). I obtained

> Please look at the thread "Python bindings in tree" starting on 2012-03-16. > There are at least four Python binding projects currently running. (None of > them in GSoC) > > I think it's a great idea to improve llvm-py, but I'd also suggest to first > look at the other bindig projects. > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/thread.html

Dear LLVM developers: Here is my another proposal of LLVM. Any suggestion would be welcome! * ** * *** Integrate Baggy Bounds Checking into SAFECode*** * * *Abstract:** * Baggy Bounds Checking (BBC) is an efficient bounds checking technique that pad and align objects to powers of two and enable allocation bounds. It uses a contiguous array as bounds table to enable

Abstraction ---------------------------------- This projects will enhance the ‘Baggy Bounds with Accurate Checking’ [1] work. I will provide more efficient runtime checks in BBAC framework by adding more informations to the memory object’s padding area. A new padding area scheme will be designed to make these informations compact and efficient to fetch. I will create some new runtime checks on

Hi Elena, You're correct. LLVM does not align the stack to 32-bytes for AVX and unaligned moves should be used for YMM spills. I wrote some code to align the stack to 32-bytes when AVX spills are present; it does break the x86-64 ABI though. If upstream would be interested in this code, I can arrange with my employer to send a patch to the mailing list. -Cameron On Mar 1, 2012, at 4:09 PM,

On Thu, Mar 1, 2012 at 4:29 PM, Evandro Menezes <emenezes at codeaurora.org>wrote: ... > Aligning the stack to 32 bytes when there are auto AVX vector variables > present shouldn't necessarily break the x86-64 ABI, as long as smaller auto > variables remain properly aligned. A similar approach was taken for i386 > in GCC in order to support SSE vectors. > > Perhaps

On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally <cameron.mcinally at nyu.edu>wrote: > Aligning the stack to 32 bytes when there are auto AVX vector variables >> present shouldn't necessarily break the x86-64 ABI, as long as smaller auto >> variables remain properly aligned. A similar approach was taken for i386 >> in GCC in order to support SSE vectors. >>

On Mar 1, 2012, at 3:04 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > Aligning the stack to 32 bytes when there are auto AVX vector variables present shouldn't necessarily break the x86-64 ABI, as long as smaller auto variables remain properly aligned. A similar approach

Cameron, Aligning the stack to 32 bytes when there are auto AVX vector variables present shouldn't necessarily break the x86-64 ABI, as long as smaller auto variables remain properly aligned. A similar approach was taken for i386 in GCC in order to support SSE vectors. Perhaps you could elaborate where the ABI was violated when your patch is applied. HTH -- Evandro Menezes

With Debug mode, it shows the assert error: Assertion failed: (I != BlockLiveness.end() && "Predecessor not found"), function calculateLocalLiveness, file lib/CodeGen/StackColoring.cpp, line 782. 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'busybox/archival/libarchive/decompress_bunzip2.c'. 4. Running

Does BTRFS perform any journal and/or filesystem structure alignment (for benefit to SSD longevity and SSD, RAID array and large-sector device performance) at present? ext4''s Ted Tso will deliver 128KB alignment with the next release of e2fsprogs (ie 1.41.4) [1], so perhaps it''s a good idea for btrfsprogs also, if not already available? Daniel --- [1]

Even if you explicitly specify –stack-alignment=16 the aligned movs are still generated. It is not an issue related to ABI. See my original mail: ./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm | grep rbp vmovaps -176(%rbp), %ymm14 vmovaps -144(%rbp), %ymm11 vmovaps -240(%rbp), %ymm13 - Elena From: Cameron McInally

All, Consider: BagA <- c(-1000,10,10,10,10,10,10, 10,20,20,20,20,20,20,30, 30,40,40,50,60) BagB <- c(10,20,30,30,40,40,50,50, 50,50,50,50,60,60,60,60, 60,60,60,1000) layout(c(2,1)) barplot(table(BagB)) barplot(table(BagA)) At this point, I'd like to arrange the plots so that the 10-bars are aligned, the 20-bars are aligned, etc. So, I started

On 8 March 2010 19:51, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > 2. I notice that the setAlignment method for an AllocaInst takes an > unsigned. For 64 bit systems, alignment could potentially be larger. Is > there a reason why the alignment should be restricted to this size? > Thanks in advance > Would it ever be practical to align a stack variable to an 8 GiB

Good evening, I understand that NTFS & VMDK do not relate to Solaris or ZFS, but I was wondering if anyone has any experience of checking the alignment of data blocks through that stack? I have a VMware ESX 4.0 host using storage presented over NFS from ZFS filesystems (recordsize 4KB). Within virtual machine VMDK files, I have formatted NTFS filesystems, block size 4KB. Dedup is turned on.

On 07/09/12 18:13, Chris Lattner wrote: > On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow

I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code in TargetData.cpp: if (GV->hasInitializer() && GVAlignment == 0) { if (Alignment < 16) { // If the global