Why the binary size in trunk are smaller significantly?

Hi all,

I am working on how to reduce the size of the binary produced for coroutine with -g.

In a private code bases, I find that the binary size produced in llvm-11 is 60M while the size produced in trunk is 51M.

I tried to find the patch who made this change in git log or in phabricator by keywords like reduce, ‘size’ or ‘binary’. But I find nothing.

May I ask does anyone knows what patch makes the binary size smaller from llvm-11 to now?

thanks,
Chuanqi

Hi Chuanqi,

In a private code bases, I find that the binary size produced in llvm-11 is 60M while the size produced in trunk is 51M.

I tried to find the patch who made this change in git log or in phabricator by keywords like `reduce`, 'size' or 'binary'. But I find nothing.

Interesting -- which sections reduce in size between llvm-11 and
trunk? Assuming you're using ELF/DWARF binaries, `readelf -W -S` will
give you sections and sizes.

Since llvm-11 branched, there were some patches [0] that improved how
variable locations are represented in DWARF, I've seen some binaries
where that reduced file size by 10%. That would be reflected in the
.debug_loc section. There's also the constructor homing flag, passed
to clang with "-Xclang -fuse-ctor-homing", I'm not sure whether it's
on by default in trunk. That would show a significant reduction in the
.debug_info section.

[0] https://reviews.llvm.org/rG0b5a8050ea39355a3876cc6bba9383d91e224e1f

Yep, I’d be curious to see more data - comparisons of sections sizes (Bloaty is a handy tool to make comparisons simpler (though for a one off might not be worth the hassle of going and downloading/building it/etc)) & any work that could be done isolating/reducing the test case (hopefully enough that it can be shared) and verifying what differences might exist between the two compilations if there’s anything other than the compiler version.

The patch that did it might have been trying to solve some unrelated problem, and this was just a side effect. Perhaps a git-bisect could help you isolate the patch?

Thanks,

Christopher Tetreault

Hi Jeremy and David,

The most significant reduction comes from the section .debug_loc and .debug_info section.
The size of .debug_info reduced about 14% and the size of of .debug_loc reduced to even 69%!

I would try the patches in the link.

Thanks,
Chuanqi

Hi Jeremy and David,

The most significant reduction comes from the section .debug_loc and .debug_info section.
The size of .debug_info reduced about 14% and the size of of .debug_loc reduced to even 69%!

Surprises me a bit, but yeah, that could be debug info related, or unrelated - optimizations might make fewer variable locations because we’ve lost track of more variables so there are no locations - or locations might be better tracked so they’re more contiguously described (so less small slices of variable locations - each slice having some overhead in its description)… but hard to say. llvm-dwarfdump --statistics might be insightful as to whether it’s improvement in locations or not. But I’d make an educated guess that this probably isn’t reflective of any bugs and is just roughly expected change from optimization changes and maybe debug info location improvements.

But I could be wrong - it is a pretty big swing, for sure.

  • Dave

Overall, thanks for your guys look into this.

Thanks,
Chuanqi

[1] https://reviews.llvm.org/D86185
[2] https://reviews.llvm.org/D96531
[3] https://reviews.llvm.org/rG7e6c87ee045497ee0b6b7e55e54921b274e8a9f2
[4] https://reviews.llvm.org/D92127
[5] https://reviews.llvm.org/rG4318028cd2d7633a0cdeb0b5d4d2ed81fab87864