Re: s390{,x} ABI incompatibility between gcc 4.0 and 4.1

[Joern RENNECKE <joern dot rennecke at st dot com>]

Jakub Jelinek wrote:

> On Tue, Nov 29, 2005 at 10:01:25PM +0000, Joern RENNECKE wrote:
>  
>
> > > If we use MIN (tree_low_cst (TYPE_SIZE (type), 0), BIGGEST_ALIGNMENT)
> > > here, I'm afraid that would be much bigger ABI incompatibility.
> > > Currently, say
> > > typedef char __attribute__((vector_size (64))) v64qi;
> > > is 64 bytes aligned on most arches, even when BIGGEST_ALIGNMENT is much
> > > smaller.
> > > GCC 4.0.x on s390{,x} aligned vector_size 1/2/4/8/64/128/... types
> > > to their size, just vector_size 16 and 32 has been 8 bytes aligned
> > > (BIGGEST_ALIGNMENT).
> > >
> > >
> > >      
> > That sounds very strange.  Is there a rationale for that, or is this a 
> > SNAFU?
> >    
>
> It is just a side-effect of the 3.4/4.0 code - if there was a supported
> integer mode on the target for the requested size, then alignment of that
> mode was used (and mode alignments are at most BIGGEST_ALIGNMENT).
> If no integer mode was supported for that size, it would use the earlier
> alignment, i.e. vector_size.
>  
I would call that a bug then.

> Unfortunately, while say vector_size (64) etc. vectors are IMHO very unlikely,
> vector_size (16) will occurr in user programs from time to time and thus the
> ABI incompatibility might affect existing programs.
> We can document the incompatibility as a feature (after all, getting
> rid of that alignment anomaly on s390{,x} wouldn't be a bad thing I guess).
>  
Having types with an alignment larger than BIGGEST_ALIGNMENT in the 
absence of
alignment attributes is also an anomaly.  And as you said, having 
vectors larger than
BIGGEST_ALIGNMENT is not as likely as having ones that are within this 
size, so making
the change to layout_struct to honour BIGGEST_ALIGNMENT for vectors 
should not cause
worse incompatibilities than doing nothing.
Now that the vector types are still rather new, we still have a 
reasonable chance to get this right
without causing too much disruption.  Fixing this at a later date will 
only get harder and harder.
Having excessive alignments for vector types would not only vaste space 
on the stack and in structures,
but also requires run-time stack aligning code and  extra overhead in 
auto-vectorized code,
and is also likely to cause failure to use vector operations at all at 
runtime because the alignment
constraints are not met.

> > > Not capping to BIGGEST_ALIGNMENT might have issues with some object formats
> > > though, if they don't support ridiculously big aligments.
> > >      
>
>  
>
> > We have MAX_OFILE_ALIGNMENT for that.
> >    
>
> But is it used for vector type alignments?
>  
It is not used for type alignments, but for variables.  Thus, structs 
that contains such vectors
still can have excessive alignment padding, but as a whole their 
alignment is restricted to
MAX_OFILE_ALIGNMENT.