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

Mon Nov 2 21:42:14 PST 2015

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

> Looking into this more, what happens at the LLVM level is that we declare
> the size to be 80 bits and to find the storage size, we round up that size
> to the ABI alignment, so I could change the verifier check to do the same,
> which would solve the immediate issue for me. However, I would still like
> to figure out the DWARF question, esp. because it will be applicable to
> `i1`.
>

What do we represent with i1? (bool?)

>
> On Mon, Nov 2, 2015 at 7:31 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>>
>>
>> On Mon, Nov 2, 2015 at 4:28 PM, Robinson, Paul <
>> Paul_Robinson at playstation.sony.com> wrote:
>>
>>> 80-bit float isn't the only case where the value-size and storage-size
>>> of a type differ.  I seem to remember reading on one of these lists, not so
>>> long ago, something from Richard Smith about how the value-size of a bool
>>> is 1 bit while its storage size is 8 bits. I've lost the context though,
>>> sorry…
>>>
>>>
>>>
>>> | 1) What's the right representation in DWARF?
>>>
>>> |
>>> | Unfortunately impossible/hard to answer. DWARF is fairly flexible &
>>> doesn't dictate "right" answers, as such.
>>>
>>> This time, actually the "right" answer is fairly clear (and in normative
>>> text, no less) right there in section 5.1.  Use DW_AT_byte_size for the
>>> storage size and DW_AT_bit_size for the value size.
>>>
>>
>> I'm not sure - it seems like a valid interpretation to believe that the
>> value is 128 bits - some of those bits are always zero. (& of course the
>> DWARF spec says "the base type entry /may/ also have", because it's all
>> permissive & stuff)
>>
>>
>>> --paulr
>>>
>>>
>>>
>>> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of
>>> *David Blaikie via llvm-dev
>>> *Sent:* Monday, November 02, 2015 4:10 PM
>>> *To:* Keno Fischer
>>> *Cc:* llvm-dev
>>> *Subject:* Re: [llvm-dev] Representing X86 long double in Debug Info
>>>
>>>
>>>
>>> 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/78a0493b/attachment.html>