TTom Stellard[LLD] [MachO] Fix GCC build warnings
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lld-macho] Devirtualize TargetInfo::getRelocAttrs This method is called on each relocation when parsing input files, so the overhead of using virtual functions ends up being quite large. We now have a single non-virtual method, which reads from the appropriate array of relocation attributes set in the TargetInfo constructor. This change results in a modest 2.3% reduction in link time for chromium_framework measured on an x86-64 VPS, and 0.7% on an arm64 Mac. N Min Max Median Avg Stddev x 10 11.869417 12.032609 11.935041 11.938268 0.045802324 + 10 11.581526 11.785265 11.649885 11.659507 0.054634834 Difference at 95.0% confidence -0.278761 +/- 0.0473673 -2.33502% +/- 0.396768% (Student's t, pooled s = 0.0504124) Differential Revision: https://reviews.llvm.org/D130000 | 3 年前 | |
[LLD] [MachO] Fix GCC build warnings This fixes the following warnings produced by GCC 9: ../tools/lld/MachO/Arch/ARM64.cpp: In member function ‘void {anonymous}::OptimizationHintContext::applyAdrpLdr(const lld::macho::OptimizationHint&)’: ../tools/lld/MachO/Arch/ARM64.cpp:448:18: warning: comparison of integer expressions of different signedness: ‘int64_t’ {aka ‘long int’} and ‘uint64_t’ {aka ‘long unsigned int’} [-Wsign-compare] 448 | if (ldr.offset != (rel1->referentVA & 0xfff)) | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../tools/lld/MachO/UnwindInfoSection.cpp: In function ‘bool canFoldEncoding(compact_unwind_encoding_t)’: ../tools/lld/MachO/UnwindInfoSection.cpp:404:44: warning: comparison between ‘enum<unnamed>’ and ‘enum<unnamed>’ [-Wenum-compare] 404 | static_assert(UNWIND_X86_64_MODE_MASK == UNWIND_X86_MODE_MASK, ""); | ^~~~~~~~~~~~~~~~~~~~ ../tools/lld/MachO/UnwindInfoSection.cpp:405:49: warning: comparison between ‘enum<unnamed>’ and ‘enum<unnamed>’ [-Wenum-compare] 405 | static_assert(UNWIND_X86_64_MODE_STACK_IND == UNWIND_X86_MODE_STACK_IND, ""); | ^~~~~~~~~~~~~~~~~~~~~~~~~ Differential Revision: https://reviews.llvm.org/D130970 (cherry picked from commit 59c6f418fa3c5d6f5c8b75ebd817be8113de7931) | 3 年前 | |
[lld-macho] Handle user-provided dtrace symbols to avoid linking failure This fixes https://github.com/llvm/llvm-project/issues/56238. ld64.lld currently does not generate __dof section in Mach-O, and -no_dtrace_dof option is on by default. However when there are user-defined dtrace symbols, ld64.lld will treat them as undefined symbols, which causes the linking to fail because lld cannot find their definitions. This patch allows ld64.lld to rewrite the instructions calling dtrace symbols to instructions like nop as what ld64 does; therefore, when encountered with user-provided dtrace probes, the linking can still succeed. I'm not sure whether support for dtrace is expected in lld, so for now I didn't add codes to make lld emit __dof section like ld64, and only made it possible to link with dtrace symbols provided. If this feature is needed, I can add that part in Dtrace.cpp & Dtrace.h. Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D129062 | 3 年前 | |
[lld-macho] Handle user-provided dtrace symbols to avoid linking failure This fixes https://github.com/llvm/llvm-project/issues/56238. ld64.lld currently does not generate __dof section in Mach-O, and -no_dtrace_dof option is on by default. However when there are user-defined dtrace symbols, ld64.lld will treat them as undefined symbols, which causes the linking to fail because lld cannot find their definitions. This patch allows ld64.lld to rewrite the instructions calling dtrace symbols to instructions like nop as what ld64 does; therefore, when encountered with user-provided dtrace probes, the linking can still succeed. I'm not sure whether support for dtrace is expected in lld, so for now I didn't add codes to make lld emit __dof section like ld64, and only made it possible to link with dtrace symbols provided. If this feature is needed, I can add that part in Dtrace.cpp & Dtrace.h. Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D129062 | 3 年前 | |
[lld-macho] Devirtualize TargetInfo::getRelocAttrs This method is called on each relocation when parsing input files, so the overhead of using virtual functions ends up being quite large. We now have a single non-virtual method, which reads from the appropriate array of relocation attributes set in the TargetInfo constructor. This change results in a modest 2.3% reduction in link time for chromium_framework measured on an x86-64 VPS, and 0.7% on an arm64 Mac. N Min Max Median Avg Stddev x 10 11.869417 12.032609 11.935041 11.938268 0.045802324 + 10 11.581526 11.785265 11.649885 11.659507 0.054634834 Difference at 95.0% confidence -0.278761 +/- 0.0473673 -2.33502% +/- 0.396768% (Student's t, pooled s = 0.0504124) Differential Revision: https://reviews.llvm.org/D130000 | 3 年前 | |
[lld-macho] Devirtualize TargetInfo::getRelocAttrs This method is called on each relocation when parsing input files, so the overhead of using virtual functions ends up being quite large. We now have a single non-virtual method, which reads from the appropriate array of relocation attributes set in the TargetInfo constructor. This change results in a modest 2.3% reduction in link time for chromium_framework measured on an x86-64 VPS, and 0.7% on an arm64 Mac. N Min Max Median Avg Stddev x 10 11.869417 12.032609 11.935041 11.938268 0.045802324 + 10 11.581526 11.785265 11.649885 11.659507 0.054634834 Difference at 95.0% confidence -0.278761 +/- 0.0473673 -2.33502% +/- 0.396768% (Student's t, pooled s = 0.0504124) Differential Revision: https://reviews.llvm.org/D130000 | 3 年前 |