[LLVMdev] global alignment

[John Criswell]

On 8/14/12 9: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.

So here's what I found:

1) We already know from Baozeng's experiments that LLVM 3.0 and Clang 
3.0 do not align globals properly when the alignment is large.

2) LLVM 3.1 will properly align globals with alignment up to 0x10000 
(which is larger than the 8192 byte alignment given in Baozeng's 
original example).  However, Clang 3.1 will assert out because it uses 
an unsigned short for representing alignments of lvalues. Changing the 
alignment class member to unsigned long magically fixes everything, and 
the code will align variables up to 0x10000 properly.

3) LLVM/Clang mainline have the same behavior as LLVM 3.1.

Baozeng, for your Baggy Bounds Checking work, the upgrade to LLVM 
mainline that SAFECode is currently undergoing will just fix the problem 
that you're seeing.  You and I can discuss separately whether to make 
the LLVM mainline switch for BBC during GSoC.

As for the bug in Clang, I'll file a bug report.

-- John T.


>
> 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] __attribute__((aligned(4096)));
>   printf("x is %p\n", x);
>   printf("y is %p\n", y);
>
>   return 0;
> }
>
> After compiled with clang, the result is:
> x is 0x804b000
> y is 0xbf9d8000
>
> They are both aligned to be 4096 as we expected.
>
> Then we change the example as the following:
>
> char x[4000] __attribute__((aligned(8192)));
>
> int
> main (int argc, char ** argv) {
>   char y[4000] __attribute__((aligned(8192)));
>   printf("x is %p\n", x);
>   printf("y is %p\n", y);
>
>   return 0;
> }
>
> The result is :
> x is 0x804d000
> y is 0xbffd2000
>
> We can see that the stack value y is aligned to be 8192, but the 
> global value x is not!
>
> My target OS is 32-bit Linux. Anyone can explain this? or is this a 
> bug of clang?
>
>
>
>
> -- 
>      Best Regards,
> Baozeng Ding
> OSTG,NFS,ISCAS
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120814/563c69b1/attachment.html>