representation of struct field offsets

[Chris Lattner]

On Oct 1, 2006, at 7:57 PM, Richard Kenner wrote:

>>> It can't be normalized to BITS_PER_UNIT, but to DECL_OFFSET_ALIGN  
>>> since
>>> we are asserting that DECL_FIELD_OFFSET is aligned to  
>>> DECL_OFFSET_ALIGN.
>>
>> That doesn't make sense to me.  It seems to me that we can  
>> normalize it
>> however we please; ultimately, all these representations just give  
>> us a
>> way of computing the first bit of the field.  We presently choose to
>> normalize to DECL_OFFSET_ALIGN, but we could just as well choose to
>> normalize to BITS_PER_UNIT.  So long as we can compute the starting
>> offset of the field, why does it matter what the normalization  
>> constant is?
>
> Because in order to generate code for an extraction, you have to know
> the alignment and offset from that alignment.  The bit position
> is essentially V * U + O where U and O are always constants but V  
> might be
> variable.  In this case U is the "unit" of the alignment, which might
> be BITS_PER_UNIT, BITS_PER_WORD, or something else. 'O' is the  
> offset in
> bits from that alignment.
>
> In other words, if we have:
>
> 	double foo[x];
> 	int fld1:27;
> 	int fld2:16;
>
> we know that fld2 is 27 bits past a 64-byte alignment boundary and we
> generate code accordingly.  So in this case DECL_FIELD_OFFSET is an
> expression involving "x", DECL_OFFSET_ALIGN is 64, and  
> DECL_FIELD_BIT_OFFSET
> is 27.  So we compute the address using DECL_FIELD_OFFSET, then pass
> down the alignment of 64 and bit offset of 27.
>
> If you merge 24 of the bits into DECL_FIELD_OFFSET and take them  
> out of
> DECL_FIELD_BIT_OFFSET, DECL_FIELD_OFFSET is no longer aligned to 64
> bits, so you'd have to set DECL_OFFSET_ALIGN to 8 and lose the  
> information
> that there was 64 bit alignment there.  Now this is a much more  
> expensive
> operation (since it crosses three alignment boundaries).

Richard,

This single mail from you has suddenly completely answered a number  
of my long-standing questions about GCC trees.  Would it be possible  
to merge this example into c-tree.texi or some other relevant place?

-Chris