On Mon, Mar 26, 2012 at 9:43 AM, Eric Botcazou <ebotca...@adacore.com> wrote:
>> Isn't DECL_OFFSET_ALIGN completely useless if it is "relative"?
>
> Good question.
The only use of DECL_OFFSET_ALIGN I see is in stor-layout.c itself:
/* If this field ended up more aligned than we thought it would be (we
approximate this by seeing if its position changed), lay out the field
again; perhaps we can use an integral mode for it now. */
if (! integer_zerop (DECL_FIELD_BIT_OFFSET (field)))
actual_align = (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1)
& - tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1));
else if (integer_zerop (DECL_FIELD_OFFSET (field)))
actual_align = MAX (BIGGEST_ALIGNMENT, rli->record_align);
else if (host_integerp (DECL_FIELD_OFFSET (field), 1))
actual_align = (BITS_PER_UNIT
* (tree_low_cst (DECL_FIELD_OFFSET (field), 1)
& - tree_low_cst (DECL_FIELD_OFFSET (field), 1)));
else
actual_align = DECL_OFFSET_ALIGN (field);
/* ACTUAL_ALIGN is still the actual alignment *within the record* .
store / extract bit field operations will check the alignment of the
record against the mode of bit fields. */
which again computes a "relative" actual_align. Removing DECL_OFFSET_ALIGN
would also get rid of that odd scaling of operand 2 of COMPONENT_REFs.
>> But I wonder how we can even detect non-byte-alignment? I see the field has
>> DECL_ALIGN of 1, but isn't that "relative" as well? At least I'm totally
>> confused with DECL_OFFSET_ALIGN being "relative".
>
> DECL_ALIGN is supposed to be the absolute counterpart. I think we indeed
> can't
> really in stor-layout, so the only place is very likely get_bit_range.
OTOH if DECL_ALIGN is absolute then if the first field of a record type has
DECL_ALIGN that is a multiple of BITS_PER_UNIT we know we can use
the present stor-layout code? So we can check that and give up computing
representatives at all for a record type if that does not hold.
Richard.
> --
> Eric Botcazou
