On a statically linked clang.exe, this shrinks the ~17 MB string
table by around 0.5 MB. This adds ~160 ms to the linking time
which originally was around 950 ms.
I've seen an extreme case where the string table would have been
shrunk from 149 MB to 107 MB though. (llvm-objcopy uses
StringTableBuilder, and thus a no-op copy with llvm-objcopy
currently optimizes the string table.)
Given the modest savings (and a noticable slowdown), do you
think is a worthwhile optimization to do, or should we just
keep things as-is?
For cases where -debug:symtab or -debug:dwarf isn't set, the
string table is only used for long section names, where this
shouldn't make any difference at all.
This requires D120676, because with this in place, strings for long
section names can be placed anywhere in the string table, and the
sprintf overflow becomes a real issue in large executables.