[llvm-commits] [llvm-gcc-4.2] r53572 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

[Dale Johannesen]

On Jul 15, 2008, at 2:00 PMPDT, Duncan Sands wrote:

> Hi Dale,
>
>>>> +    // For ObjC2, we may have a base class field that should not
>>>> be taken into
>>>> +    // account here, as it is already in Offset.  The ObjC FE
>>>> figures this out.
>>>> +    tree field_bit_offset = objc_v2_bitfield_ivar_bitpos(exp);
>>>> +    if (field_bit_offset) {
>>>> +      BitStart = (unsigned)getINTEGER_CSTVal(field_bit_offset);
>>>> +    }
>>>>    // Here BitStart gives the offset of the field in bits from
>>>> field_offset.
>>>>    // Incorporate as much of it as possible into the pointer
>>>> computation.
>>>>    unsigned ByteOffset = BitStart/8;
>>>
>>> I didn't understand from your description what is going on here.
>>> Can you
>>> please explain some more.
>>
>> I'll try.  Bitfields are referenced by an offset in bytes relative to
>> the beginning of the
>> object, + an offset in bits relative to the byte offset.  In ObjC V2
>> the byte offset
>> can change at runtime, so is loaded from memory rather than computed
>> at compile
>> time.  The value loaded from memory includes the value you would
>> normally get
>> at compile time, so you don't want to add that in twice.  There is
>> analogous code
>> in non-llvm-gcc's get_inner_reference.
>> (The comment about a base class is wrong, I'll fix that.)
>
> thanks for the explanation.  However llvm-gcc already supports
> variable byte-offsets, i.e. where the value of the byte offset
> depends on the value of some variable, the content of a memory
> location etc.  Ada does this for example.  So why does ObjC2
> need something special here?

Presumably the ObjC FE trees do not look like the Ada trees.
I don't know what the Ada trees look like.
In ObjC, the offset is actually there twice in the tree in effect ,  
and the user
needs to compensate at some stage.  Don't ask me why, I didn't write  
it:)