llvm dev - Jan 2016 - Representing X86 long double in Debug Info

Adrian Prantl via llvm-dev wrote on Mon, 02 Nov 2015:
> 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.
The x86-64 and Darwin/i386 ABI define the size of the 80 bits extended  
type in memory as 16 bytes. In all other i386 ABIs, it's defined as 12  
bytes. Delphi and, for compatibility reasons, the Free Pascal Compiler  
use 10 bytes (although FPC also has a "cextended" type that follows  
the official ABI for the platform). In FPC we use a [10 x i8] for all  
memory representations of the non-ABI 80 bits extended type.

So ideally, the bitsize of the type should be specifiable separately  
from the ABI/TypeInfo, as there may be multiple in the code.


Jonas

I'd like to revive this thread again, because the same problematic has come
up again. Originally I solved this problem by asking llvm for the AllocSize
(i.e. the size including padding), which solves the fp80 case nicely, but
e.g. also gives 32 for {i8, i8, i8}. For now I think the only thing I can
do is make the verifier accept either size, but I would like to discuss
whether we can represent the difference in IR such that we can tighten the
check.

On Tue, Nov 3, 2015 at 9:16 AM, Jonas Maebe via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> Adrian Prantl via llvm-dev wrote on Mon, 02 Nov 2015:
>
> 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.
>>
>
> The x86-64 and Darwin/i386 ABI define the size of the 80 bits extended
> type in memory as 16 bytes. In all other i386 ABIs, it's defined as 12
> bytes. Delphi and, for compatibility reasons, the Free Pascal Compiler use
> 10 bytes (although FPC also has a "cextended" type that follows
the
> official ABI for the platform). In FPC we use a [10 x i8] for all memory
> representations of the non-ABI 80 bits extended type.
>
> So ideally, the bitsize of the type should be specifiable separately from
> the ABI/TypeInfo, as there may be multiple in the code.
>
>
> Jonas
>
> _______________________________________________
> 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/20160113/c0fa0f0e/attachment.html>

On Wed, Jan 13, 2016 at 2:52 PM, Keno Fischer via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I'd like to revive this thread again, because the same problematic has
> come up again. Originally I solved this problem by asking llvm for the
> AllocSize (i.e. the size including padding), which solves the fp80 case
> nicely, but e.g. also gives 32 for {i8, i8, i8}.
>
Not sure I follow - why would the allocsize of {i8, i8, i8} be 32? An array
of them would presumably have elements that are 3 bytes, not 4?

> For now I think the only thing I can do is make the verifier accept either
> size, but I would like to discuss whether we can represent the difference
> in IR such that we can tighten the check.
>
> On Tue, Nov 3, 2015 at 9:16 AM, Jonas Maebe via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> Adrian Prantl via llvm-dev wrote on Mon, 02 Nov 2015:
>>
>> 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.
>>>
>>
>> The x86-64 and Darwin/i386 ABI define the size of the 80 bits extended
>> type in memory as 16 bytes. In all other i386 ABIs, it's defined as
12
>> bytes. Delphi and, for compatibility reasons, the Free Pascal Compiler
use
>> 10 bytes (although FPC also has a "cextended" type that
follows the
>> official ABI for the platform). In FPC we use a [10 x i8] for all
memory
>> representations of the non-ABI 80 bits extended type.
>>
>> So ideally, the bitsize of the type should be specifiable separately
from
>> the ABI/TypeInfo, as there may be multiple in the code.
>>
>>
>> Jonas
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> _______________________________________________
> 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/20160115/731becd9/attachment.html>