@tejohnson noticed that freeing MemoryBuffer instances right before
lto->compile can save RSS, likely because the memory can be reused by
LTO indexing (e.g. ThinLTO import/export lists).).
For ELFFileBase instances, symbol and section names are backed by MemoryBuffer,
so destroying MemoryBuffer would make some infrequent passes (parseSymbolVersion,
reportBackrefs) crash and make debugging difficult.
For a BitcodeFile, its content is completely unused, but destroying its
MemoryBuffer makes the buffer identifier inaccessible and may introduce
constraints for future changes.
This patch leverages madvise(MADV_DONTNEED) which achieves the major gain
without the latent issues.
Maximum resident set size (kbytes): for a large --thinlto-index-only link:
- current behavior: 10146104KiB
- destroy MemoryBuffer instances: 8555240KiB
- madvise(MADV_DONTNEED) just bitcodeFiles and lazyBitcodeFiles: 8737372KiB
- madvise(MADV_DONTNEED) all MemoryBuffers: 8739796KiB
Depends on D116366