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

Mon Nov 2 22:45:31 PST 2015

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

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

i1 even for a function parameter, struct member, etc? Again, I'd be
confused by how that works/how LLVM decides to use a whole byte for it, etc.

>
> 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/20151102/14efca97/attachment.html>