Re: i386 alignment tweaks...

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, 14 Jan 2000 at 12:26:22 -0800, Richard Henderson wrote:
> On Thu, Jan 13, 2000 at 01:27:33PM +0100, Jan Hubicka wrote:
> > I've been experimenting a bit with using fild/fist instruction to
> > move DImode values and using them in memset/memcpy expanders.
> > I've run into problems with gcc roudning alignment
> > to BIGGEST_ALIGNMENT, that is defined to 32 only.
> > From the docs I think, we can define BIGGEST_ALIGNMENT to real biggest
> > alignment (128 bits for XFmode) and use BIFFEST_FIELD_ALIGNMENT to
> > preserve ABI compatibility.
> >
> > This can avoid unnecesary roudning, but I am not sure that it will
> > not break ABI (while grepping gcc sources one of places I am not sure
> > about are bitfields).
> ...
> >    * i386.h (BIGGEST_ALIGNMENT): Set to 128.
> >    (BIGGEST_FIELD_ALIGNMENT): Set to (TARGET_ALIGN_DOUBLE ? 64 : 32)
>
> This part is ok.

This part is definitely not ok, it terribly breaks the x86 ABI in multiple
ways:

a) union { double d; int a[3]; } has now different value of __alignof__ and
size.
b) struct { double d __attribute__((aligned(32))); int a; } has now
different value of __alignof__ and size.
c) typedef double dbl __attribute__((aligned(8))); struct { dbl d; int a; }
has now different value of __alignof__ and size.
(and likewise with long long or long double instead of double).

(in the first case, alignof and size is bigger than it used to be, in the
latter cases it is smaller because BIGGEST_FIELD_ALIGNMENT unconditionally
wraps any special alignment.

Now what I see how this can be fixed:

I) revert this part of the patch (that should work, but will needlessly kill
performance
II) keep track on whether a DECL_ALIGN and/or TYPE_ALIGN results from the
natural alignment of the decl/type or if it was changed by A_ALIGNED.
This bit would have to be inherited when e.g. setting DECL_ALIGN from
TYPE_ALIGN. If we have such information, then we can introduce some
BIGGEST_INITIAL_FIELD_ALIGNMENT macro on arches which need it, which would
work like BIGGEST_FIELD_ALIGNMENT with the following difference:
- it would only cap the alignment if alignment was not specifically
requested by A_ALIGNED
- it would be used both in place_field and place_union_field (this would fix
a) as well).

Now, II) looks like a better thing for x86 to me, because plain
double d;
outside of structure will still make the object aligned to 8 bytes to make
things fast, but if it is within the structure or union, it will not break
the ABI.
I'll try to code it, unless I hear strong arguments against it.

	Jakub