[llvm-commits] [llvm-gcc-4.2] r47403 - in /llvm-gcc-4.2/trunk/gcc: config/i386/i386-protos.h config/i386/i386.c config/i386/llvm-i386-target.h llvm-abi.h

Dale Johannesen dalej at apple.com
Thu Feb 21 11:48:30 PST 2008


On Feb 21, 2008, at 1:27 AM, Duncan Sands wrote:

> Hi,
>
>> +/* Objects containing SSE vectors are 16 byte aligned, everything  
>> else 4. */
>
> so packed structs are passed 4 byte aligned?

Yes.

>  Can you not use the type alignment here?

The alignment in the type nodes refers to the alignment within larger  
objects.  The alignment when passed as a parameter is not the same in  
some cases (e.g. long double).

While working on this I found that the parameter alignment for 64-bit  
(MMX) vectors (on x86-32) is given as 8 in X86CallingConv, but it  
should be 4 for Darwin.  Would you check what it should be on Linux?   
Thanks.

<mounts soapbox>
Part of the reason this stuff is so confusing is that people refer to  
"the alignment" of a type, when this is not really meaningful.  Types  
are aligned differently in different situations.  There are at least  
the following cases:

a) Alignment within a larger object
b) Alignment when passed as a parameter (which can be different for  
varargs and non-varargs functions)
c) Alignment of variables (conceivably different for static, global  
and auto)
d) Alignment required by the hardware for instructions to work (i.e.  
if "packed" results in alignments less than this, the compiler has to  
generate special code for those fields)

For Darwin long double, a=16, b=4, c=16, d=1.  For Darwin long long,  
a=4, b=4, c=8 (this is what gcc's alignof returns), d=1.

And there are curiosities beyond this:  on Darwin PPC, a double as the  
first field of a struct causes the struct to be 8-byte aligned, but a  
double elsewhere in the struct is 4-byte aligned.  Try coming up with  
a nice abstraction for that one.

However gcc, llvm, and at least 2 language standards blithely refer to  
"the alignment" without further qualification, so this problem isn't  
going away soon.




More information about the llvm-commits mailing list