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

[David Blaikie via llvm-dev]

To come back to the original question: Doesn't LLVM know somewhere that
x86_fp80 requires 128 bits of storage? (eg: how does it layout the call
argument for an x86_fp80 if it's not being passed in a register? How does
it layout the stack containing one of these?)

I /imagine/ somewhere in LLVM knows about the need for 128 bits of storage
for these things, and we should be using that information to cross
reference with the debug info.

(aside: I don't think there's much merit to DWARF consumers to add this
extra info - if they've all been surviving without it for this long)

On Mon, Nov 2, 2015 at 2:47 PM, Keno Fischer <kfischer at college.harvard.edu>
wrote:

> 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?
>

Unfortunately impossible/hard to answer. DWARF is fairly flexible & doesn't
dictate "right" answers, as such.

GCC produces only the byte_size, as Clang/LLVM does. I don't know what GDB
(or LLDB, or anything else) would do with the additional
bit_size/data_bit_offset. I doubt any of them are designed to do anything
with it, at best they'll ignore it & that'll be fine.


> 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`
>

Maybe the other way around (so we don't change the semantics of an existing
field & have to worry about breaking back compat?) - the new/differently
named field should describe the new thing we want to add, the actual
functional size (not sure what to name it, though)?


> 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/4927c519/attachment.html>