Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[Jason Merrill <jason at redhat dot com>]

On Thu, 24 Apr 2003 15:31:39 -0400, Geert Bosch <bosch at gnat dot com> wrote:

> On Thursday, Apr 24, 2003, at 13:16 America/New_York, Jason Merrill wrote:
>> I was referring to what dewar said here:
>>
>> On Mon, 21 Apr 2003 17:35:51 -0400 (EDT), dewar at gnat dot com (Robert Dewar)
>> wrote:
>>
>>>   type A is ...
>>>
>>>   B : A;
>>>   for B'Alignment use 4;
>>>
>>>   Put_Line (Integer'Image (B'Alignment));
>>>
>>> This must output 4. Of course the compiler could still silently put
>>> B on a bigger alignment, since there would be no way to tell that it
>>> was doing this systematically, but this would be a poor implementation.

>> To me, this means that DECL_ALIGN for B must be exactly 4, whereas giving
>> A a TYPE_ALIGN of 4 would only mean that DECL_ALIGN for B must be at
>> least 4.
>
> Exactly. A TYPE_ALIGN of 4 means that any variable of the type is
> aligned to at least 4. So the maximum alignment the compiler can
> assume for any pointer to a 4-byte aligned type is 4.

Agreed.

>>> Specifying an alignment for an object means "don't reduce". Of course
>>> the compiler should have a good reason to increase, but that's a
>>> quality of implementation issue. For example, a compiler might well
>>> align all 14-byte local objects of a 2-byte aligned type to 16 bytes
>>> and then take advantage of that stricter alignment in code generation.
>
>> This seems to conflict with what dewar is saying.

> No it does not. Note that this is the case where no DECL_ALIGN has been
> specified.

Huh?  The testcase quoted above specifies the alignment for an object,
which to me means setting DECL_ALIGN.

> Such as:
>    type T is record
>       X, Y, Z : Unsigned_16; -- 16-bit unsigned type
>    end T;
>    for T'Size use 48; --  48 bits
>    for T'Alignment use 2;
>
>    R : T := (1, 2, 3);
>    Put (R'Alignment);
>
> This may output a value that is a multiple of 2.

Agreed.  But what do you think about dewar's testcase?

>> 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.
> Note where you write "field", this really means "component of a
> composite type", where a composite type can either be a record
> or array.

Good point.  But how would this be represented for an array?  I suppose by
reducing TYPE_ALIGN on the element type, so we need to be able to do that
as well.

>> 4) For objects, we want to be able to force a minimum alignment.
> Yes, where minimum alignment is not smaller than the type alignment.

Yes.

>> 5) For objects, we want to be able to force an exact alignment for
>> building up special sections (and for other reasons?).
> How would this interact with reordering of objects (for example,
> sorting by decreasing size, or for increasing cache efficiency)?
> Also, do we guarantee that the compiler will not decide to output
> extra objects between user-defined ones?

Good point; presumably we would want the same flag to suppress all such
optimizations.

>> 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.
>>
>> It seems to me that the question people have been arguing about is what
>> to do about the distinction between 4 and 5.  I think that
>> DECL_USER_ALIGN was intended to mean 2, which logically extends to 4.
> Agreed.
>>
>> rth's patch of 2001-08-15 changed it to mean 5.
>>
>> It makes sense to inherit DECL_USER_ALIGN from TYPE_USER_ALIGN if it
>> means 4, but not if it means 5; that's why we're seeing the S/390 problem.
>
> I don't think inheriting is a good idea, even for 4. This way
> we loose the capability to over-align objects for which no specific
> alignment was specified.

No, we don't.  4 just specifies a minimum; you can still over-align such an
object.  According to dewar, specifying the alignment for an object in Ada
means both 4 and 5.  It's not clear to me that we want the internal
representation to work the same way.

> It is important that we can do this, especially as it allows small
> records to be stored in registers.

Agreed.

>> There would seem to be two ways to fix this:
>>
>> A) Stop inheriting DECL_USER_ALIGN from TYPE_USER_ALIGN on VAR_DECLs.
>> B) Change DECL_USER_ALIGN to mean 4, and use DECL_PACKED to mean 5.
>>
>> I'm partial to solution B.  Other opinions?
>
> I'm in favor of A, since it differentiates between the case where
> the compiler has freedom to choose the alignment that gives the
> most efficient code on each machine and the case where the user
> has good reasons to pin down the details.

Both solutions do that.  It's just a question of which flag to use
internally.

Jason