search for: dibasetype

Displaying 4 results from an estimated 4 matches for "dibasetype".

Did you mean: basetype
2014 Oct 24
8
[LLVMdev] First-class debug info IR: MDLocation
...the following: !0 = metadata DIFile(filename: "foo.cpp", directory: "/path/to") !1 = metadata DIFile(filename: "./t.h", directory: "/path/to") !2 = metadata DIFile(filename: "bar.cpp", directory: "/path/to") !3 = metadata DIBaseType(name: "short", size: 16, align: 16) !5 = metadata DIBaseType(name: "int", size: 32, align: 32) !6 = metadata DICompositeType(tag: 0x13, name: "T", uniqued: "_ZTS1T", file: !1, line: 1, size: 32, align: 16) !7 = me...
2015 Nov 02
4
Representing X86 long double in Debug Info
...scribe 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 i...
2015 Nov 03
2
Representing X86 long double in Debug Info
...(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 ba...
2015 Nov 02
2
Representing X86 long double in Debug Info
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