search for: dievalu

...11 203 652946 12 245 653191 It's crazy that we're paying for 12 up front on every DIE. (This is a reformatted version of num-values-with-totals.txt, which I've attached along with a few other histograms Pete collected.) The `DIEValue`s themselves, which get leaked on the BumpPtrAllocator, also take up a huge amount of memory (around 4%): Graph Category Persistent Bytes # Persistent # Transient Total Bytes # Total Transient/Total Bytes 0 llvm::DIEInteger 19.91 MB 652389 0 19.91 MB 652389 <XRRatioObject: 0x608025658...

With just those four patches, memory usage went *up* slightly. Add in the 5th patch (which does #2 below), and we get an overall memory drop of 4%. The intermediate result of a memory increase makes sense. While the first four patches reduce the number of (and size of) `DIEValue` allocations, they increase the cost of the `SmallVector` overhead. 0005 (attached) squeezes the abbreviation data into `DIEValue` for free, next to the discriminator for the union. The 5 patches together are strictly an improvement to memory usage. It's nice to see the 4% memory drop, but t...

...I've cleaned all this up and committed the most obvious parts, as well as a few unrelated memory improvements. I'm attaching my (almost?) ready-to-go patches, which have the following effects on peak memory: - 0000: 845 MB (baseline) - 0001: 845 MB - refactor - 0002: 879 MB - pass DIEValue by value (momentary setback) - 0003: 829 MB - merge DIEAbbrevData into DIEValue - 0004: 829 MB - refactor - 0005: 829 MB - refactor - 0006: 829 MB - refactor - 0007: 764 MB - change DIE::Values to a linked list - 0008: 756 MB - change DIE::Children to a linked list (Still measuring me...

...and I have a few ideas in mind for how to reduce its memory consumption. One idea I've had is to restructure the emitter so that (for the most part) it directly produces the bytes and relocations that need to go into the DWARF sections without going through other data structures such as DIE and DIEValue. I understand that the DWARF emitter needs to accommodate incomplete entities that may be completed elsewhere during tree construction (e.g. abstract origins for inlined functions, special members for types), so here's a quick high-level sketch of the data structures that I believe could supp...

...ed to from the DW_TAG_compile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything looks to be in order. Here is a short description of what the patches accomplish die.patch: adds a new DIEValue type to represent a section relative label. (their was already a type id specified so I provided a class modeled after DIELabel) secrel-fixup.patch: creats a new target specific fixup type (reloc_coff_secrel32) to represent COFF Section Relative relocations and updats the COFF object writer to...

...pile_unit DIE. I have run some basic tests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything looks to be in order. > > Here is a short description of what the patches accomplish > > die.patch: > adds a new DIEValue type to represent a section relative label. (their was already a type id specified so I provided a class modeled after DIELabel) > > secrel-fixup.patch: > creats a new target specific fixup type (reloc_coff_secrel32) to represent COFF Section Relative relocations and updats the COFF ob...

...o reduce its memory consumption. One > > idea I've had is to restructure the emitter so that (for the most part) it > > directly produces the bytes and relocations that need to go into the DWARF > > sections without going through other data structures such as DIE and > > DIEValue. > > > > I understand that the DWARF emitter needs to accommodate incomplete > > entities > > that may be completed elsewhere during tree construction (e.g. abstract > > origins > > for inlined functions, special members for types), so here's a quick > &g...

...ve run some basic tests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything looks to be in order. >> >> Here is a short description of what the patches accomplish >> >> die.patch: >> adds a new DIEValue type to represent a section relative label. (their was already a type id specified so I provided a class modeled after DIELabel) >> >> secrel-fixup.patch: >> creats a new target specific fixup type (reloc_coff_secrel32) to represent COFF Section Relative relocations and updats...

...ests, analyzed dumps of both the objects files and the final executables, and run a test program against mingw-gdb and everything looks to be in order. >>> >>> Here is a short description of what the patches accomplish >>> >>> die.patch: >>> adds a new DIEValue type to represent a section relative label. (their was already a type id specified so I provided a class modeled after DIELabel) >>> >>> secrel-fixup.patch: >>> creats a new target specific fixup type (reloc_coff_secrel32) to represent COFF Section Relative relocations...