[all-commits] [llvm/llvm-project] bb69a6: [lld-macho] Coalesce local symbol aliases along wi...

[Jez Ng via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bb69a66ced27918f894fb0d5e58e22fda6958d99
      https://github.com/llvm/llvm-project/commit/bb69a66ced27918f894fb0d5e58e22fda6958d99
  Author: Jez Ng <jezng at fb.com>
  Date:   2023-03-11 (Sat, 11 Mar 2023)

  Changed paths:
    M lld/MachO/InputFiles.cpp
    M lld/MachO/SymbolTable.cpp
    A lld/test/MachO/local-alias-to-weak.s
    R lld/test/MachO/private-label-alias.s

  Log Message:
  -----------
  [lld-macho] Coalesce local symbol aliases along with their aliased weak def

This supersedes {D139069}. 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} and
{D139069} 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...

Reviewed By: lgrey

Differential Revision: https://reviews.llvm.org/D145455


  Commit: 5b21395cc2422d735c632afefcb95f08d8ed4b88
      https://github.com/llvm/llvm-project/commit/5b21395cc2422d735c632afefcb95f08d8ed4b88
  Author: Jez Ng <jezng at fb.com>
  Date:   2023-03-11 (Sat, 11 Mar 2023)

  Changed paths:
    M lld/MachO/MapFile.cpp
    M lld/test/MachO/map-file.ll
    M lld/test/MachO/map-file.s

  Log Message:
  -----------
  [lld-macho] Print archive names in linker map

If a symbol is pulled in from an archive, we should include the archive
name in the map file output. This is what ld64 does.

Note that we aren't using `toString(InputFile*)` here because it
includes the install name for dylibs in its output, and ld64's map file
does not contain those.

Reviewed By: #lld-macho, smeenai

Differential Revision: https://reviews.llvm.org/D145623


  Commit: dd78e7334fc5eb4a3253433fe6dd80e440b5f7cc
      https://github.com/llvm/llvm-project/commit/dd78e7334fc5eb4a3253433fe6dd80e440b5f7cc
  Author: Jez Ng <jezng at fb.com>
  Date:   2023-03-11 (Sat, 11 Mar 2023)

  Changed paths:
    M lld/MachO/InputFiles.cpp
    M lld/MachO/MapFile.cpp
    M lld/MachO/Symbols.h
    M lld/test/MachO/map-file.s

  Log Message:
  -----------
  [lld-macho] Don't include zero-size private label symbols in map file

This is also what ld64 does. This will make it easier to compare their
respective map files.

Reviewed By: #lld-macho, thevinster

Differential Revision: https://reviews.llvm.org/D145654


Compare: https://github.com/llvm/llvm-project/compare/3b4cb1e96c64...dd78e7334fc5