[PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)

[Alan Modra]

On Fri, Jun 14, 2013 at 12:54:40PM +0200, Jakub Jelinek wrote:
> On Fri, Jun 14, 2013 at 08:12:02PM +0930, Alan Modra wrote:
> > I see your point, but for there to be a real problem we'd need
> > a) A library exporting such a type with (supposed) increased
> >    alignment, and,
> > b) gcc would need to make use of the increased alignment.
> > 
> > (a) must be rare or non-existent or you'd think we would have had a
> > bug report about lack of user alignment in vector typedefs.  The code
> > has been like this since 2001-11-07, so users have had a long time to
> > discover it.  (Of course, this is an argument for just ignoring the
> > bug too.)
> 
> It doesn't have to be an exported symbol from a library, it is enough to
> compile some objects using one compiler and other objects using another
> compiler, then link into the same library.

OK.

> Try (long) &x & 31; ?  That &x & -32 not being optimized into &x
> is guess a missed optimization.

Huh, trust me to hit another bug. :)

> Consider if you put:
> typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
> vec_align x = { 0, 0, 0, 0 };
> into one TU and compile with gcc 4.8.1, then
> typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
> extern vec_align x;
> 
> long f1 (void)
> {
>   return (long) &x & 31;
> }
> in another TU and compile with gcc trunk after your patch.  I bet
> it will be optimized into return 0; by the trunk + your patch compiler,
> while the alignment will be actually just 16 byte.

Right.  Counterpoint is that gcc made exactly the same sort of error
across TUs and even in the same TU prior to my change.  eg.

typedef int vec_align __attribute__ ((vector_size(16), aligned(32)));
vec_align x = { 0, 0, 0, 0 };
long f1 (void) { return (long)&x & 31; }
int y __attribute__ ((vector_size(16), aligned(32))) = { 0, 0, 0, 0 };
long f2 (void) { return (long)&y & 31; }

compiles to

.L.f1:
        li 3,0
        blr
..
.L.f2:
        li 3,0
        blr
..
        .globl y
        .lcomm  y,16,32
        .type   y, @object
        .globl x
        .lcomm  x,16,16
        .type   x, @object
        .ident  "GCC: (GNU) 4.7.2 20120921 (Red Hat 4.7.2-2)"

My implementation of rs6000_data_alignment therefore doesn't introduce
a *new* ABI incompatibility.  I question whether it is worth
complicating rs6000_data_alignment, especially since your suggestion
of using the older buggy alignment in DATA_ABI_ALIGNMENT then
increasing in DATA_ALIGNMENT isn't as simple as it sounds.  We're
not talking about some fixed increase in DATA_ALIGNMENT but what we
want is the value of alignment before DATA_ABI_ALIGNMENT.  Perhaps
that could be retrieved from TYPE_ALIGN (type) and
MAX_OFILE_ALIGNMENT, but that would make our DATA_ALIGNMENT the only
target to need such tricks.

-- 
Alan Modra
Australia Development Lab, IBM