This supersedes D139069: [lld-macho] Private label aliases to weak symbols should not retain section data. In some ways we are now closer to ld64's
behavior: we previously only did this coalescing for private-label
symbols, but now we do it for all locals, just like ld64. However, we no
longer generate weak binds when a local alias to a weak symbol is
referenced. This is merely for implementation simplicity; it's not clear
to me that any real-world programs depend on us emulating this behavior.
The problem with the previous approach is that we ended up with
duplicate references to the same symbol instance in our InputFiles,
which translated into duplicate symbols in our output. While we could
work around that problem by performing a dedup step before emitting the
symbol table, it seems cleaner to not generate duplicate references in
the first place.
Numbers for chromium_framework on my 16 Core Intel Mac Pro:
base diff difference (95% CI) sys_time 2.243 ± 0.093 2.231 ± 0.066 [ -2.5% .. +1.4%] user_time 6.529 ± 0.087 6.080 ± 0.050 [ -7.5% .. -6.3%] wall_time 6.928 ± 0.175 6.474 ± 0.112 [ -7.7% .. -5.4%] samples 26 31
Yep, that's a massive win... because it turns out that D140606: [lld-macho] Only fold private-label aliases that do not have flags and
D139069: [lld-macho] Private label aliases to weak symbols should not retain section data caused a regression (of about the same size.) I just didn't
think to measure them back then. I'm guessing all the extra symbols we
have been emitting did not help perf at all...
insertIt