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.
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).
>
> >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?
Jakub
