On Thu, Mar 28, 2024 at 6:04 AM Alan Modra <amo...@gmail.com> wrote: > > On Fri, Mar 22, 2024 at 06:51:41PM -0700, Fangrui Song wrote: > > On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song <mask...@gcc.gnu.org> wrote: > > > I propose RELLEB, a new format offering significant file size > > > reductions: 17.2% (x86-64), 16.5% (aarch64), and even 32.4% (riscv64)! > > > > > > Your thoughts on RELLEB are welcome! > > Does anyone really care about relocatable object file size? If they > do, wouldn't they be better off using a compressed file system?
Yes, many people care about relocatable file sizes. * Relocation sizes affect DWARF evolution and we were/are using an imperfect metric due to overly bloated REL/RELA. .debug_str_offsets does not get much traction in GCC, probably partly because it needs relocations. DWARF v5 introduced changes to keep relocations small. Many are good on their own, but we need to be cautious of relocation concerns causing us to pick the wrong trade-off in the future. * On many Linux targets, Clang emits .llvm_addrsig by default to allow ld.lld --icf=safe. .llvm_addrsig stores symbol indexes in ULEB128 instead of using relocations to prevent a significant size increase. * Static relocations make .a files larger. * Some users care about the build artifact size due to limited disk space. + I believe part of the reasons -ffunction-sections -fdata-sections do not get more adoption is due to the relocatable file size concern. + I prefer to place build directories in Linux tmpfs. 12G vs 10G in memory matters to me :) + Large .o files => more IO amount. This may be more significant when the storage is remote.
