search for: debugfission

...ur work for compressing DWARF data motivated by a certain > inefficiency in debug info representation? Did it result in significant savings? > > > > The compression isn't related to the IR level and some data is here on that > compressing: > > https://gcc.gnu.org/wiki/DebugFission > > The internal representation and code have change significantly since then > and there's no real way to help much. It may be a memory leak, but I don't > recall one that bad back then. How is your customer compiling? LTO? > Something else? > > -eric > > >...

...iency in debug info representation? Did it result in significant > savings? > >> > > >> > >> The compression isn't related to the IR level and some data is here > >> on that > >> compressing: > >> > >> https://gcc.gnu.org/wiki/DebugFission > >> > >> The internal representation and code have change significantly since > >> then and there's no real way to help much. It may be a memory leak, > >> but I don't recall one that bad back then. How is your customer compiling? > LTO? > >>...

...I have attached a document consolidating it. BOLT’s performance gains inspired this work and we believe BOLT is a great piece of engineering. However, there are build environments where scalability is critical and memory limits per process are tight : * Debug Fission, https://gcc.gnu.org/wiki/DebugFission was primarily invented to achieve scalability and better incremental build times while building large binaries with debug information. * ThinLTO, http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html was primarily invented to make LLVM’s full LTO scalable and keep the memory and t...

David, Thanks for the quick response... No, at this point I am just getting into the issue... I assume it is a leak, but no clear proof yet. I was hoping it was an obvious thing since I recall a discussion about it a while ago... but maybe I am just confused. Was your work for compressing DWARF data motivated by a certain inefficiency in debug info representation? Did it result in

Is there large value from deferring the block ordering to link time? That is, does the block layout algorithm need to consider global layout issues when deciding which blocks to put together and which to relegate to the far-away part of the code? Or, could the propellor-optimized compile step instead split each function into only 2 pieces -- one containing an "optimally-ordered" set of

...gt; > > > BOLT’s performance gains inspired this work and we believe BOLT > > is a great piece of engineering. However, there are build environments > where > scalability is critical and memory limits per process are tight : > > * Debug Fission, https://gcc.gnu.org/wiki/DebugFission was primarily > invented to achieve scalability and better incremental build times while > building large binaries with debug information. > > * ThinLTO, > http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html > <https://urldefense.proofpoint.com/v2/url?u=http-...

...p?title=COMDAT_Type_Sections 10. DWARF Extensions for Unwinding Across Merged Functions     http://wiki.dwarfstd.org/index.php?title=ICF 11. Type Unit Merge     http://dwarfstd.org/ShowIssue.php?issue=130526.1 12. DWARF Extensions for Separate Debug Information Files     https://gcc.gnu.org/wiki/DebugFission 13. dwz dwarf compressor     http://sourceware.org/git/dwz.git 14. DWARF5 standard     http://dwarfstd.org/Dwarf5Std.php ===================================================================== Appendix B. List of improvements which are not done by this patch.   1. Type hash calculation should not...

...gt; > > > BOLT’s performance gains inspired this work and we believe BOLT > > is a great piece of engineering. However, there are build environments > where > scalability is critical and memory limits per process are tight : > > * Debug Fission, https://gcc.gnu.org/wiki/DebugFission was primarily > invented to achieve scalability and better incremental build times while > building large binaries with debug information. > > * ThinLTO, > http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html > <https://urldefense.proofpoint.com/v2/url?u=http-...

...gt; > > > BOLT’s performance gains inspired this work and we believe BOLT > > is a great piece of engineering. However, there are build environments > where > scalability is critical and memory limits per process are tight : > > * Debug Fission, https://gcc.gnu.org/wiki/DebugFission was primarily > invented to achieve scalability and better incremental build times while > building large binaries with debug information. > > * ThinLTO, > http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html > <https://urldefense.proofpoint.com/v2/url?u=http-...

Some more information about the relaxation pass whose effectiveness and convergence guarantees were listed as a concern: TLDR; Our relaxation pass is similar to what LLVM’s MCAssembler does but with a caveat for efficiency. Our experimental results show it is efficient and convergence is guaranteed. Our relaxation pass is very similar to what MCAssembler does as it needs to solve the same