On Thu, Jan 2, 2014 at 11:18 PM, Eric Botcazou <ebotca...@adacore.com> wrote: >> Note that it has unexpected side-effects: previously, in 32-bit mode, >> 256-bit aggregate objects would have been given 256-bit alignment; now, >> they will fall back to default alignment, for example 32-bit only. > > In case this wasn't clear enough, just compile in 32-bit mode: > > int a[8] = { 1, 2, 3, 4, 5, 6, 7, 8};
It looks to me that we don't need to adjust anything with max_align. Using following patch: --cut here-- Index: i386.c =================================================================== --- i386.c (revision 206311) +++ i386.c (working copy) @@ -26465,6 +26465,7 @@ int ix86_data_alignment (tree type, int align, bool opt) { +#if 0 int max_align = optimize_size ? BITS_PER_WORD : MIN (512, MAX_OFILE_ALIGNMENT); @@ -26476,6 +26477,7 @@ || TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < max_align) align = max_align; +#endif /* x86-64 ABI requires arrays greater than 16 bytes to be aligned to 16byte boundary. */ --cut here-- and following testcase: -- cut here-- float a[8] = { 1, 2, 3, 4, 5, 6, 7, 8}; extern float z[8]; void t (void) { int i; for (i = 0; i < 8; i++) z[i] = z[i] + a[i]; } --cut here-- When compiled with -m32 -mavx, we get: .align 32 .type a, @object .size a, 32 a: so, the alignment was already raised elsewhere. We get .align 16 for -msse -m32 when vectorizing. without -msse (and consequently without vectorizing), we get for -m32: .align 4 .type a, @object .size a, 32 a: which corresponds to 32bit ABI rules (we still get .align16 for 64bit ABI). What bothers me in this testcase is (unrelated) alignment of z[8] array. Even for 64bit targets, we get: #(insn:TI 6 5 8 2 (set (reg:V4SF 21 xmm0 [orig:90 vect__4.5 ] [90]) # (unspec:V4SF [ # (mem/c:V4SF (reg/f:DI 0 ax [89]) [2 MEM[(float *)&z]+0 S16 A32]) # ] UNSPEC_LOADU)) al.c:10 1195 {*sse_loadups} # (nil)) movups (%rax), %xmm0 # 6 *sse_loadups [length = 3] ABI guarantees 16 byte alignment of z[8], but we fail to communicate this to the compiler. Uros.