search for: dw_tag_enumerator

...t you need multiple abbreviations for each DIType, > in order to represent DITypes formed of multiple DIEs (e.g. enums, records)? > > Maybe something like this would work: > > $1 = { DIAbbrev: 0x1234, DIBlob: DW_TAG_enumeration_type<blah> } > $2 = { DIAbbrev: 0x5678, DIBlob: DW_TAG_enumerator<blah> } > $3 = { DIType: <ID>, DIAbbrev: [(0, $1), (8, $2), (16, $2)], DIBlob: <8 > bytes of DW_TAG_enumeration_type attrs><8 bytes of DW_TAG_enumerator > attrs><8 bytes of DW_TAG_enumerator attrs><0> } > > ? > *nod* That (or something similar)...

...Makes sense, but wouldn't you need multiple abbreviations for each DIType, in order to represent DITypes formed of multiple DIEs (e.g. enums, records)? Maybe something like this would work: $1 = { DIAbbrev: 0x1234, DIBlob: DW_TAG_enumeration_type<blah> } $2 = { DIAbbrev: 0x5678, DIBlob: DW_TAG_enumerator<blah> } $3 = { DIType: <ID>, DIAbbrev: [(0, $1), (8, $2), (16, $2)], DIBlob: <8 bytes of DW_TAG_enumeration_type attrs><8 bytes of DW_TAG_enumerator attrs><8 bytes of DW_TAG_enumerator attrs><0> } ? > >> >> Any other concerns there? >>>...

...for each >> DIType, in order to represent DITypes formed of multiple DIEs (e.g. enums, >> records)? >> >> Maybe something like this would work: >> >> $1 = { DIAbbrev: 0x1234, DIBlob: DW_TAG_enumeration_type<blah> } >> $2 = { DIAbbrev: 0x5678, DIBlob: DW_TAG_enumerator<blah> } >> $3 = { DIType: <ID>, DIAbbrev: [(0, $1), (8, $2), (16, $2)], DIBlob: <8 >> bytes of DW_TAG_enumeration_type attrs><8 bytes of DW_TAG_enumerator >> attrs><8 bytes of DW_TAG_enumerator attrs><0> } >> >> ? >> > >...

...39;t you need multiple abbreviations for each DIType, in order to represent DITypes formed of multiple DIEs (e.g. enums, records)? > > Maybe something like this would work: > > $1 = { DIAbbrev: 0x1234, DIBlob: DW_TAG_enumeration_type<blah> } > $2 = { DIAbbrev: 0x5678, DIBlob: DW_TAG_enumerator<blah> } > $3 = { DIType: <ID>, DIAbbrev: [(0, $1), (8, $2), (16, $2)], DIBlob: <8 bytes of DW_TAG_enumeration_type attrs><8 bytes of DW_TAG_enumerator attrs><8 bytes of DW_TAG_enumerator attrs><0> } > > ? > > *nod* That (or something similar) wil...

On Tue, Mar 29, 2016 at 7:31 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sharing this. Mostly seems like a reasonable plan to me. A few > comments below. > > Thanks Peter! > On Tue, Mar 29, 2016 at 6:00 PM, Eric Christopher via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi All, >> >> This is something that's been

...: x <4c> DW_AT_type : <0x6d> ... ... <2><5f>: Abbrev Number: 5 (DW_TAG_enumeration_type) <60> DW_AT_name : (indirect string, offset: 0x140): .llvm.aux.attr <64> DW_AT_byte_size : 0 <3><65>: Abbrev Number: 6 (DW_TAG_enumerator) <66> DW_AT_name : (indirect string, offset: 0x13c): .ID <6a> DW_AT_const_value : 1234 By DW_TAG_enumeration_type '.llvm.aux.attr', we can connect an attribute named ".ID" to this structure type, whose value should be 1234. Note that enumeration ty...

On 2015/8/4 3:44, Alexei Starovoitov wrote: [SNIP] >> I'll post 2 LLVM patches by replying this mail. Please have a look and >> help me >> send them to LLVM if you think my code is correct. > > [SNIP] > patch 2: > do we really need to hack clang? > Can you just define a function that aliases to intrinsic, > like we do for ld_abs/ld_ind ? > void

This is for BPF output. BPF program output bytes to perf through a tracepoint. For decoding such data, we need a way to describe the format of the buffer. This patch is a try which gives each variable a unique number by introducing a new intrinsic 'llvm.typeid.for'. At the bottom is an example of using that intrinsic and the result of $ clang -target bpf -O2 -c -S ./test_typeid.c

...><2a>: Abbrev Number: 2 (DW_TAG_enumeration_type) <2b> DW_AT_name : (indirect string, offset: 0xec): TYPEINFO <2f> DW_AT_byte_size : 4 <30> DW_AT_decl_file : 1 <31> DW_AT_decl_line : 3 <2><32>: Abbrev Number: 3 (DW_TAG_enumerator) <33> DW_AT_name : (indirect string, offset: 0xcc): __typeinfo_strA <37> DW_AT_const_value : 2 <2><38>: Abbrev Number: 3 (DW_TAG_enumerator) <39> DW_AT_name : (indirect string, offset: 0xdc): __typeinfo_strB <3d> DW_A...

...ck Tag = 52, Count = 9933, Ops = 59598, Name = DW_TAG_variable Tag = 33, Count = 190, Ops = 190, Name = DW_TAG_subrange_type Tag = 59, Count = 1, Ops = 3, Name = DW_TAG_unspecified_type Tag = 40, Count = 24731, Ops = 24731, Name = DW_TAG_enumerator Tag = 21, Count = 354166, Ops = 2833328, Name = DW_TAG_subroutine_type Tag = 2, Count = 77999, Ops = 623992, Name = DW_TAG_class_type Tag = 47, Count = 27122, Ops = 108488, Name = DW_TAG_template_type_parameter Tag = 28, Count = 8491, Ops = 33964...

In r219010, I merged integer and string fields into a single header field. By reducing the number of metadata operands used in debug info, this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and I've concluded that they will be insufficient. Instead, I'd like to implement a more aggressive plan,