[llvm] [AArch64, ELF] Allow implicit $d/$x at section beginning (PR #99718)
Fangrui Song via llvm-commits
llvm-commits at lists.llvm.org
Fri Aug 9 11:28:46 PDT 2024
MaskRay wrote:
Thanks for the table:)
> default | covers all cases but too many mapping symbols
This is theoretically true.
That said, I have notes that GNU assembler's AArch32/AArch64 implementations omit mapping symbols in some cases, therefore not covering all cases
https://maskray.me/blog/2024-07-21-mapping-symbols-rethinking-for-efficiency#peculiar-alignment-behavior-in-gnu-assembler
> On reflection I think putting the trailing $x in is probably the least worst optimised solution as I expect it is the least likely to cause problems.
Thank you for acknowledging the benefits of the ending mapping symbol:)
> Is there a strong objection to optimising this at link time? There would be some run-time overhead to scan for redundant $x and removing them, but this would always give the same answer as the current default.
Yes, to maitain relocatable file size and preserve the current linker performance.
My preliminary analysis revealed that making lld smarter will cause significant performance overhead
https://sourceware.org/pipermail/binutils/2024-July/135992.html
I have maded a local change to lld that stable sorts local symbols by address.
This results in a 5% increase in link time, making it impractical for
default on.
Tangentially, Chrome is now exploring CREL. Perhaps Android will follow up as well.
Reduced relocatable file size is particularly important for large projects.
* For me, .o file size impacts the number of LLVM project builds I can store in a tmpfs filesystem. Large projects like Chrome often require 100GB+, creating significant disk space requirement for users. Even a single-digit percentage reduction in size is highly beneficial.
* File transfer overhead is larger when the network is involved, which is an essential part of distributed build systems. There are costs like computing a digest (for deduplication/Bazel style build system) and others.
https://github.com/llvm/llvm-project/pull/99718
More information about the llvm-commits
mailing list