[llvm-dev] Representing X86 long double in Debug Info

[Keno Fischer via llvm-dev]

That was essentially part of my question. The DWARF standard says:

If the value of an object of the given type does not fully occupy the
> storage described by a byte size attribute, the base type entry may also
> have a DW_AT_bit_size and a DW_AT_data_bit_offset attribute, both of whose
> values are integer constant values (see Section 2.19). The bit size
> attribute describes the actual size in bits used to represent values of the
> given type. The data bit offset attribute is the offset in bits from the
> beginning of the containing storage to the beginning of the value. Bits
> that are part of the offset are padding.


which made me think the representation I proposed in the original email
might be correct (i.e. an 80bit value, but always stores as 16 bytes).

As far as I see it, there's 3 questions here:

1) What's the right representation in DWARF?
2) If we think it should be the byte_size/bit_size combination, how do we
describe this in IR, because right now, even though the size is in bits,
will always emit `DW_AT_byte_size $(size>>3)`
3) How would clang describe this in it's TargetInfo

Just to throw my opinion out there:

1) Use the DW_AT_bit_size/DW_AT_byte_size
2) Add a new `storage_size` attribute to DIBaseType that is generally equal
to size, except in cases like this, where we should have `storage_size =
128, size = 80`
3) Have clang set those based on `getLongDoubeSize` (for storage size) and
`getLongDoubleFormat` as Reid suggested. This did seem very hacky too me at
first as well, but thinking about it again, the format does encode how many
semantic bits there are (because it is needed for correctly constant
folding etc.), which is really what we're asking for here.

However, I personally don't have strong opinions, as long as there's
something consistent I can implement in the verifier.

On Mon, Nov 2, 2015 at 5:26 PM, David Blaikie <dblaikie at gmail.com> wrote:

> I'm a bit confused by all this - sizeof(long double) is 16 bytes (128
> bits). I /think/ that's what we should be describing, even if some of
> that's essentially padding?
>
> On Mon, Nov 2, 2015 at 1:04 PM, Reid Kleckner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Mon, Nov 2, 2015 at 8:38 AM, Adrian Prantl via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Looking at the code in clang CGDebugInfo just passes through the width
>>> of the type as it is described by the TypeInfo, which in turn is defined by
>>> the Target. At the moment I do not understand why an x86_fp80 is reported
>>> to be 128 bits wide. (Since it’s a type natively supported by LLVM
>>> http://llvm.org/docs/LangRef.html#floating-point-types I would have
>>> expected it to be more like size=80, align=128)
>>>
>>> This looks like a bug to me and the debug info should describe an
>>> x86_fp80 as being 80 bits wide, but I don’t understand the mechanics well
>>> enough to decide whether the TypeInfo is wrong here or if we should work
>>> around it in CGDebugInfo.
>>>
>>
>> I think TypeInfo usually describes the answer that sizeof() is supposed
>> to give. sizeof() is typically a multiple of alignment, so if alignof() is
>> 128, sizeof must be 128. Other common alignments are 32 and 64, which makes
>> sizeof() 96 and 128 respectively. In practice, sizeof(long double) is never
>> 80.
>>
>> Maybe CGDebugInfo should ask TargetInfo::getLongDoubleFormat() what model
>> is in use and generate dwarf accordingly. It's a bit of a hack, so I'm open
>> to better suggestions.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/84974760/attachment.html>