DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Richard Kenner]

    > No, it's being overloaded for two *other* meanings:
    > 
    > (1) The user really did set the alignment of the object.
    > (2) The user really did set the alignment of the object's *type*.

    I see the two as equivalent.

I see them as very different because the semantics of setting the alignment
of a type and of an object are fundamentally different.  The first has both
efficiency and code generation impact, but the second has only the latter.

This is codified in the Ada RM, but actually applies to all languages.

When you set the alignment of a *type*, you are making an interface statement
about that type, more specifically about pointers to that type.  You are
requiring the compiler to align any objects of that type that it creates to
be at least as aligned as you specify but *also* stating that any objects of
that type *imported* to the code will have that minimum alignment, but aren't
guaranteeing it will have more than that alignment.  So the compiler is not
permitted to assume a larger alignment when it generates code to access
objects of that type (via a pointer, when it knows nothing else about the
object itself).

This means that the specification of the alignment of a type bounds the
compiler on both sides: it must ensure that any object it makes is *no less*
aligned, but it cannot generate code that assumes the alignment is *more*
than that specified.

So if the alignment of a type is specified, the alignment of the type cannot
be changed by the compiler: it must either honor that alignment or give an
error.

But specifying the alignment of an *object* is very different.  It's not
making a statement about an interface, but about efficiency.  If I specify
the alignment of an object, I'm asserting that I've analyzed accesses to the
object and determined the optimal alignment.

In which cases is the compiler allowed to override a user-specified
alignment?  Well, for types it must *never* override the alignment since that
would be an interface violation.

For objects, if an object is at least as aligned as that requested, it's
fine, so I'd argue that a compiler should feel free to over-align an object
for efficiency reasons even if the type's alignment is specified because
there's no reason not to.  On the other hand, if the *object's* alignment is
specified, one can presume it was done with a knowlege of what the optimal
alignment was so that overriding it is not a good idea.

However, if it *has* to be overriden, such as for the minimum alignment of
S390, it certainly *should* be since it's not an error to increase the
alignment of an object (as opposed to a type).

But, in some sense, this isn't even the point.

My major point is that decision of what alignment to actually give an
object may depend on lots of things, including:

(1) the target machine
(2) the language
(3) the mode and alignment of the type
(4) whether the alignment of the type was user-specified
(5) the alignment of the object
(6) whether the alignment of the object was user-specified

What we're doing now is not providing #6, but instead providing the "or"
of #4 and #6.  I see no justification for elminating potentially-useful
information.