search for: dievaluelist

...If I understand correctly the numbers, this does not tell anything about how much the Dwarf emitter accounts on the *peak memory* usage (could be more, could be nothing...). I think these nodes represent allocations from the DWARF emitter: DwarfDebug::DwarfDebug 9.5% DwarfDebug::endFunction 15.6% DIEValueList::addValue 9.1% total 34.2% I believe they are totals, but my reading of the code is that the DWARF emitter does not deallocate its memory until the end of code generation, so total ~= peak in this case. I am not surprised by these figures -- see e.g. DIEValueList::Node which in the worst case can...

...gt; about how much the Dwarf emitter accounts on the *peak memory* usage (could > be more, could be nothing...). > > > > I think these nodes represent allocations from the DWARF emitter: > > > > DwarfDebug::DwarfDebug 9.5% > > DwarfDebug::endFunction 15.6% > > DIEValueList::addValue 9.1% > > total 34.2% > > > > I believe they are totals, but my reading of the code is that the DWARF > > emitter does not deallocate its memory until the end of code generation, > > That's sad :( > > > so total ~= peak in this case. > > Ass...

...emitter accounts on the *peak memory* usage (could >> be more, could be nothing...). >> > >> > I think these nodes represent allocations from the DWARF emitter: >> > >> > DwarfDebug::DwarfDebug 9.5% >> > DwarfDebug::endFunction 15.6% >> > DIEValueList::addValue 9.1% >> > total 34.2% >> > >> > I believe they are totals, but my reading of the code is that the DWARF >> > emitter does not deallocate its memory until the end of code generation, >> >> That's sad :( >> >> > so total ~=...

Hi all, We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and we've found that one of the top consumers of memory is the DWARF emitter in lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code 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