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

Mon Nov 2 22:32:38 PST 2015

Yes, I was thinking of bool. Clang emits it as 8 bits in debug info, but
uses i1 in the IR, so e.g. what do I do if an i1 is passed to a dbg.value.

On Tue, Nov 3, 2015 at 12:42 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> 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/20151103/a072cbb0/attachment-0001.html>