aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python
diff options
context:
space:
mode:
authorJez Ng <jezng@fb.com>2022-07-23 12:11:46 -0400
committerJez Ng <jezng@fb.com>2022-07-23 12:12:01 -0400
commitd23da0ec6c539fa380b7552a99e6922efe7a55e8 (patch)
tree9ee8ec15f6455cb5db51e99afd6743b716fd9d23 /lldb/source/Plugins/ScriptInterpreter/Python
parent676a03d8a5e325d8a3f92c1fb37ab0a8ae78b6e1 (diff)
downloadllvm-d23da0ec6c539fa380b7552a99e6922efe7a55e8.zip
llvm-d23da0ec6c539fa380b7552a99e6922efe7a55e8.tar.gz
llvm-d23da0ec6c539fa380b7552a99e6922efe7a55e8.tar.bz2
[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
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python')
0 files changed, 0 insertions, 0 deletions