[all-commits] [llvm/llvm-project] d23da0: [lld-macho] Fold __objc_imageinfo sections

[Jez Ng via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d23da0ec6c539fa380b7552a99e6922efe7a55e8
      https://github.com/llvm/llvm-project/commit/d23da0ec6c539fa380b7552a99e6922efe7a55e8
  Author: Jez Ng <jezng at fb.com>
  Date:   2022-07-23 (Sat, 23 Jul 2022)

  Changed paths:
    M lld/MachO/Driver.cpp
    M lld/MachO/InputFiles.cpp
    M lld/MachO/InputFiles.h
    M lld/MachO/InputSection.h
    M lld/MachO/SyntheticSections.cpp
    M lld/MachO/SyntheticSections.h
    M lld/MachO/Writer.cpp
    M lld/test/MachO/builtin-rename.s
    A lld/test/MachO/objc-imageinfo.s

  Log Message:
  -----------
  [lld-macho] Fold __objc_imageinfo sections

Previously, we treated it as a regular ConcatInputSection. However, ld64
actually parses its contents and uses that to synthesize a single image
info struct, generating one 8-byte section instead of `8 * number of
object files with ObjC code`.

I'm not entirely sure what impact this section has on the runtime, so I
just tried to follow ld64's semantics as closely as possible in this
diff. My main motivation though was to reduce binary size.

No significant perf change on chromium_framework on my 16-core Mac Pro:

             base           diff           difference (95% CI)
  sys_time   1.764 ± 0.062  1.748 ± 0.032  [  -2.4% ..   +0.5%]
  user_time  5.112 ± 0.104  5.106 ± 0.046  [  -0.9% ..   +0.7%]
  wall_time  6.111 ± 0.184  6.085 ± 0.076  [  -1.6% ..   +0.8%]
  samples    30             32

Reviewed By: #lld-macho, thakis

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