Re-apply "[NFCI][LTO][lld] Optimize away symbol copies within LTO global resolution in ELF"

[mingmingl-llvm]

Fix the use-after-free bug and re-apply #106193

• Without the fix, the string referenced by objSym.Name could be destroyed even if string saver keeps a copy of the referenced string. This caused use-after-free.
• The fix (latest commit) updates objSym.Name to reference (via StringRef) the string saver's copy.

Test:

1. For lld/test/ELF/lto/asmundef.ll, its test failure is reproducible with -DLLVM_USE_SANITIZER=Address and gone with the fix.
2. Run all tests by following https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild#try-local-changes.
   • Without the fix, ELF/lto/asmundef.ll aborted the multi-stage test at @@@BUILD_STEP stage2/asan_ubsan check@@@, defined here
   • With the fix, the multi-stage test pass stage2 {asan, ubsan, masan}. This is also the test used by https://lab.llvm.org/buildbot/#/builders/169

Original commit message

StringMap<T> creates a copy of the string for entry insertions and intentionally keep copies since the implementation optimizes string memory usage. On the other hand, linker keeps copies of symbol names [1] in lld::elf::parseFiles [2] before invoking compileBitcodeFiles [3].

This change proposes to optimize away string copies inside LTO::GlobalResolutions, which will make LTO indexing more memory efficient for ELF. There are similar opportunities for other (COFF, wasm, MachO) formats.

The optimization takes place for lld (ELF) only. For the rest of use cases (gold plugin, llvm-lto2, etc), LTO owns a string saver to keep copies and use global resolution key for de-duplication.

Together with @kazutakahirata's work to make ComputeCrossModuleImport more memory efficient, we see a ~20% peak memory usage reduction in a binary where peak memory usage needs to go down. Thanks to the optimization in 329ba52, the max (as opposed to the sum) of ComputeCrossModuleImport or GlobalResolution shows up in peak memory usage.

• Regarding correctness, the set of resolved per-module symbols is a subset of llvm::lto::InputFile::Symbols. And bitcode symbol parsing saves symbol name when iterating obj->symbols in BitcodeFile::parse already. This change updates BitcodeFile::parseLazy to keep copies of per-module undefined symbols.
• Presumably the undefined symbols in a LTO unit (copied in this patch in linker unique saver) is a small set compared with the set of symbols in global-resolution (copied before this patch), making this a worthwhile trade-off. Benchmarking this change alone shows measurable memory savings across various benchmarks.

[1] ELF

llvm-project/lld/ELF/InputFiles.cpp

Line 1748 in 1cea5c2

sym = symtab.insert(saver().save(objSym.getName()));

[2]

llvm-project/lld/ELF/Driver.cpp

Line 2863 in ef7b18a

parseFiles(files, armCmseImpLib);

[3]

llvm-project/lld/ELF/Driver.cpp

Line 2995 in ef7b18a

compileBitcodeFiles<ELFT>(skipLinkedOutput);

[jvoung]

The unique_saver is now moved out, so should this comment be moved up too and merged with the "Keep copies of per-module undefined symbols" in some way?

[mingmingl-llvm]

done.

[teresajohnson]

lgtm with a couple of comment fixes

[teresajohnson]

s/class/struct/

[mingmingl-llvm]

done.

[teresajohnson]

Maybe update the comment a bit since it only talks about undefined symbols but now applies to both. Probably pull up the other comment below on line 1806 and combine them?

[mingmingl-llvm]

done.