DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jason Merrill]

On Thu, 24 Apr 2003 10:32:14 -0700, Zack Weinberg <zack@codesourcery.com> wrote:

> Jason Merrill <jason@redhat.com> writes:
>
>> 1) For types, we want to be able to force a minimum alignment for
>>   efficiency/correctness of access.
>> 2) For fields, we want to be able to force a minimum alignment.
>> 3) For fields, we want to be able to reduce alignment for packing efficiency.
>> 4) For objects, we want to be able to force a minimum alignment.
>> 5) For objects, we want to be able to force an exact alignment for building
>>   up special sections (and for other reasons?).
>>
>> Anything else?
>>
>> 1 is handled by TYPE_ALIGN/TYPE_USER_ALIGN.
>> 2 and 4/5 are handled by DECL_ALIGN/DECL_USER_ALIGN.
>> 3 is handled by DECL_PACKED.
>
> I'm leery of bringing DECL_PACKED into this -- the "packed" concept
> has never really been nailed down as far as I know, and I worry that
> it might bring in a whole 'nother set of conflicting assumptions from
> the user community of __attribute__ ((packed)).

It seems pretty clear to me, though the comment in tree.h is wrong.
__attribute ((packed)) means use the smallest alignment possible, unless a
greater alignment is specified with __attribute ((aligned (n))).  So
DECL_PACKED means "don't pad to an alignment greater than DECL_ALIGN".

> My suggestion would be that we rip out all the existing ALIGN stuff in
> favor of two TYPE fields and two DECL fields named TYPE_MIN_ALIGN,
> TYPE_MAX_ALIGN, DECL_MIN_ALIGN, and DECL_MAX_ALIGN.

This sounds interesting, but I think that one integer and two flags is
actually what we need.

> The semantics are that *_MIN_ALIGN is the minimum alignment to enforce
> for a type or object

Yes.

> and *_MAX_ALIGN is the maximum alignment that can be assumed for a type
> or object.

No!  That's another meaning of *_MIN_ALIGN.  The enforced alignment is also
the alignment that can be assumed.  These are the two parties to the
alignment contract.

DECL_MAX_ALIGN would be the maximum alignment that can be applied to an
object.  But if you want to specify a maximum alignment at all, I can't
think of a situation in which we would a maximum different from the
minimum, so a flag should be adequate.

We also still need to be able to suppress the effects of
BIGGEST_FIELD_ALIGNMENT, which is why we have DECL_USER_ALIGN in the first
place.

So, we need:

A numerical alignment.
A flag which says "no, really, don't reduce the alignment, even if the ABI
  says to."
A flag which says "don't add extra padding."

It's not clear to me that we need the second flag for types.
The first flag is only really meaningful for FIELD_DECLs, and the second is only
really meaningful for VAR_DECLs.

Currently, both flags use DECL_USER_ALIGN.

Option A is to declare this to be intended, and make the one-line fix to
do_type_align to only copy TYPE_USER_ALIGN to DECL_USER_ALIGN for
FIELD_DECLs.

Option B is to use a different macro for the second flag.  DECL_PACKED
already means "don't increase the alignment", so it seems appropriate to
use it in this context, too.

Currently, there's no way to declare a misaligned VAR_DECL.  Do we care?

Jason