[all-commits] [llvm/llvm-project] 817d98: [lld-macho][nfc] Refactor in preparation for 32-bi...

[Jez Ng via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 817d98d84186c3508ba7a9a58202e616b23f344a
      https://github.com/llvm/llvm-project/commit/817d98d84186c3508ba7a9a58202e616b23f344a
  Author: Jez Ng <jezng at fb.com>
  Date:   2021-04-02 (Fri, 02 Apr 2021)

  Changed paths:
    M lld/MachO/Arch/ARM64.cpp
    M lld/MachO/Arch/X86_64.cpp
    M lld/MachO/Driver.cpp
    M lld/MachO/DriverUtils.cpp
    M lld/MachO/InputFiles.cpp
    M lld/MachO/InputFiles.h
    M lld/MachO/InputSection.cpp
    M lld/MachO/LTO.cpp
    M lld/MachO/MachOStructs.h
    M lld/MachO/ObjC.cpp
    M lld/MachO/SyntheticSections.cpp
    M lld/MachO/SyntheticSections.h
    M lld/MachO/Target.h
    M lld/MachO/UnwindInfoSection.cpp
    M lld/MachO/Writer.cpp
    M lld/MachO/Writer.h

  Log Message:
  -----------
  [lld-macho][nfc] Refactor in preparation for 32-bit support

The main challenge was handling the different on-disk structures (e.g.
`mach_header` vs `mach_header_64`). I tried to strike a balance between
sprinkling `target->wordSize == 8` checks everywhere (branchy = slow, and ugly)
and templatizing everything (causes code bloat, also ugly). I think I struck a
decent balance by judicious use of type erasure.

Note that LLD-ELF has a similar architecture, though it seems to use more templating.

Linking chromium_framework takes about the same time before and after this
change:

      N           Min           Max        Median           Avg        Stddev
  x  20          4.52          4.67         4.595        4.5945   0.044423204
  +  20           4.5          4.71         4.575         4.582   0.056344803
  No difference proven at 95.0% confidence

Reviewed By: #lld-macho, oontvoo

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