llvm dev - Nov 2015 - Representing X86 long double in Debug Info

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?
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`
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/84974760/attachment.html>

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>

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>

| it seems like a valid interpretation to believe that the value is 128 bits -
some of those bits are always zero

I beg to differ. We had to add hacks in some of our test scripts to detect
'long double' and ignore the other
unpredictable-and-certainly-not-always-zero bits.
--paulr

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Monday, November 02, 2015 4:31 PM
To: Robinson, Paul; llvm-dev
Cc: Keno Fischer
Subject: Re: [llvm-dev] Representing X86 long double in Debug Info



On Mon, Nov 2, 2015 at 4:28 PM, Robinson, Paul <Paul_Robinson at
playstation.sony.com<mailto: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<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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/3d031e58/attachment.html>

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

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