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

[David Blaikie via llvm-dev]

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>