search for: dw_tag_inherit

...les. My language supports the concept of a "assign once" variable (like 'final' in Java). for which I use SSA values directly rather than storage created via alloca(). Does this means that there is no way to debug such variables? 4) There seems to be something weird going on with DW_TAG_inheritance: When I print out the type in the debugger I see <> symbols: 2 = { <> = { <> = { __tib = 0x0 }, members of tart.reflect.Member: _name = 0x0, _fullName = 0x0, _kind = 0, .. etc ... I'd like to see an example of DW_TAG_inheritance in th...

This isn't a realistic/viable implementation, just a hacked up "can I make it produce the right output" kind of thing, but while I hammer out a few more details (like fixing MC to allow multiple sections with the same name but different comdat groups) I figured I'd throw it out there to have a bit of a chat about it. I've tested simple cases of a single type and they seem to

...= 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, Name = DW_TAG_inheritance Tag = 66, Count = 10930, Ops = 43720, Name = DW_TAG_rvalue_reference_type Tag = 16, Count = 54680, Ops = 218720, Name = DW_TAG_reference_type Tag = 23, Count = 624, Ops = 4992, Name = DW_TAG_union_type Tag = 4, Count = 5344, Ops = 4275...

I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM

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,