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

Mon Nov 2 16:31:26 PST 2015

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