DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT
Thu Apr 24 19:51:00 GMT 2003
On Thu, 24 Apr 2003 15:31:39 -0400, Geert Bosch <firstname.lastname@example.org> 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), email@example.com (Robert Dewar)
>>> 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.
>>> 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
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
> 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
>> 4) For objects, we want to be able to force a minimum alignment.
> Yes, where minimum alignment is not smaller than the type alignment.
>> 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
>> 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.
>> 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.
>> 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
More information about the Gcc-patches