On Thu, Jan 2, 2014 at 11:18 PM, Eric Botcazou <[email protected]> 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.