记一次gcc -O2大幅度增加binary size的问题

最新推荐文章于 2024-08-20 16:21:49 发布

电影旅行敲代码

最新推荐文章于 2024-08-20 16:21:49 发布

阅读量2.2k

点赞数 3

分类专栏：编译文章标签： c++

本文链接：https://blog.csdn.net/dashuniuniu/article/details/106316585

版权

编译专栏收录该内容

29 篇文章 24 订阅

订阅专栏

分析过程，价值不大

一、什么是O2

在编译folly的过程中，添加了-O2选项，libfolly.a的binary size从184M增加到了273M，为什么folly会增加这么多？

# default option
▶ ls -al -h | grep libfolly.a
-rw-r--r-- 1 wangliushuai wangliushuai 184M May 21 14:00 libfolly.a
# add -O2
▶ ls -al -h | grep libfolly.a
-rw-r--r-- 1 wangliushuai wangliushuai 273M May 21 11:57 libfolly.a

如果不指定任何优化选项，gcc默认是-O0，虽然是-O0，但也并不是什么优化都不做，一些简单的常量传播或者公共子表达式消除还是可以实现的。-O2会打开-O1的选项，并提供如下选项：

// The optimization flags of O1
-fauto-inc-dec 
-fbranch-count-reg 
-fcombine-stack-adjustments 
-fcompare-elim 
-fcprop-registers 
-fdce 
-fdefer-pop 
-fdelayed-branch 
-fdse 
-fforward-propagate 
-fguess-branch-probability 
-fif-conversion 
-fif-conversion2 
-finline-functions-called-once 
-fipa-profile 
-fipa-pure-const 
-fipa-reference 
-fipa-reference-addressable 
-fmerge-constants 
-fmove-loop-invariants 
-fomit-frame-pointer 
-freorder-blocks 
-fshrink-wrap 
-fshrink-wrap-separate 
-fsplit-wide-types 
-fssa-backprop 
-fssa-phiopt 
-ftree-bit-ccp 
-ftree-ccp 
-ftree-ch 
-ftree-coalesce-vars 
-ftree-copy-prop 
-ftree-dce 
-ftree-dominator-opts 
-ftree-dse 
-ftree-forwprop 
-ftree-fre 
-ftree-phiprop 
-ftree-pta 
-ftree-scev-cprop 
-ftree-sink 
-ftree-slsr 
-ftree-sra 
-ftree-ter 
-funit-at-a-time
// The optimization flags of O2
-falign-functions  -falign-jumps 
-falign-labels  -falign-loops 
-fcaller-saves 
-fcode-hoisting 
-fcrossjumping 
-fcse-follow-jumps  -fcse-skip-blocks 
-fdelete-null-pointer-checks 
-fdevirtualize  -fdevirtualize-speculatively 
-fexpensive-optimizations 
-ffinite-loops 
-fgcse  -fgcse-lm  
-fhoist-adjacent-loads 
-finline-functions 
-finline-small-functions 
-findirect-inlining 
-fipa-bit-cp  -fipa-cp  -fipa-icf 
-fipa-ra  -fipa-sra  -fipa-vrp 
-fisolate-erroneous-paths-dereference 
-flra-remat 
-foptimize-sibling-calls 
-foptimize-strlen 
-fpartial-inlining 
-fpeephole2 
-freorder-blocks-algorithm=stc 
-freorder-blocks-and-partition  -freorder-functions 
-frerun-cse-after-loop  
-fschedule-insns  -fschedule-insns2 
-fsched-interblock  -fsched-spec 
-fstore-merging 
-fstrict-aliasing 
-fthread-jumps 
-ftree-builtin-call-dce 
-ftree-pre 
-ftree-switch-conversion  -ftree-tail-merge 
-ftree-vrp

可以看到-O2开启了很多optimization flags，哪一个才是导致binary size增加这么多原因呢？

二、追查过程

首先就是通过libfolly.a本身入手，对比加-O2和不加的两者的区别，此时使用的工具是size。由于libfolly.a是archive，所以挑选其中一个典型的Future.cpp.o查看，对于-O2版本来讲，size命令显示出来的结果和ls命令显示出来的结果是相违背的。

# default option
▶ ls -al -h | grep Future.cpp.o
-rw-r--r-- 1 wangliushuai wangliushuai   19M May 21 14:08 Future.cpp.o

▶ size Future.cpp.o
   text           data            bss            dec            hex        filename
1203973           5632            177        1209782         1275b6        Future.cpp.o

# -O2
▶ ls -al -h | grep Future.cpp.o
-rw-r--r-- 1 wangliushuai wangliushuai  31M May 21 14:07 Future.cpp.o

▶ size Future.cpp.o
   text           data            bss            dec            hex        filename
 586635           4072            177         590884          90424        Future.cpp.o

ls命令得到的结果肯定是准确的，所以问题肯定处在了size命令上，查询size工具的实现原理参见https://stackoverflow.com/a/31238689/10481594，对于text列的结果是如下三个section之后（section是linker角度来看，而segment是从os运行角度来看的）：

.text
.rodata
.eh_frame

注：上图来源于http://www.skyfree.org/linux/references/ELF_Format.pdf

使用命令readelf -WS来查看object file中详细的section信息，发现有成千上万个section，但是通常的section不应该是几十个吗？像是.bss，.coment，.text，.got等等。发现很多section name是.text.mangledname的形式，这就要介绍function-level linking的概念，linker在链接时会重定位并合并相同的段，例如.text。但是有可能一个.o中有10函数，但是只被使用了一个，链接时还是会把其余的9个无用的函数链接进去。而function-level linking，则把每个函数单独分配一个section，这样的话，只有被用到的section最终会被链接进去，而对于gcc来说，可以使用-ffunction-sections来enable这个机制，然后linker使用-Wl,–gc-sections来删除无用的代码。检查folly的build文件，发现有-ffunction-sections的。

3220   [3215] .text._ZN5folly6FutureIlE6getTryEv PROGBITS        0000000000000000 022e10 000079 00 AXG  0   0 16
3221   [3216] .rela.text._ZN5folly6FutureIlE6getTryEv RELA            0000000000000000 ecf910 0000c0 18  IG 5389 3215  8
3222   [3217] .text._ZN5folly6FutureINS_4UnitEE6getTryEv PROGBITS        0000000000000000 022e90 000079 00 AXG  0   0 16
3223   [3218] .rela.text._ZN5folly6FutureINS_4UnitEE6getTryEv RELA            0000000000000000 ecf9d0 0000c0 18  IG 5389 3217  8

所以size命令无法看出两者的差别，所以只能从section header入手查看区别，首先-O2 option的function-section数量是原来的1/5。

# default option
▶ readelf -WS Future.cpp.o| grep ".text.*" |  wc -l
16210
# add -O2 option
▶ readelf -WS Future.cpp.o| grep ".text.*" |  wc -l
3260

然后随便挑选一个function section查看，我们可以看到函数
folly::exception_wrapper::InPlace<folly::FutureNoTimekeeper>::delete_(folly::exception_wrapper*)对应function section的size从0x35->0x16。

# default option
[18348] .text._ZN5folly17exception_wrapper7InPlaceINS_18FutureNoTimekeeperEE7delete_EPS0_ PROGBITS        0000000000000000 0a5dea 000035 00 AXG  0   0  2
[18349] .rela.text._ZN5folly17exception_wrapper7InPlaceINS_18FutureNoTimekeeperEE7delete_EPS0_ RELA            0000000000000000 bf5df8 000030 18  IG 25869 18348  8

# add -O2 option
[1813] .text._ZN5folly17exception_wrapper7InPlaceINS_18FutureNoTimekeeperEE7delete_EPS0_ PROGBITS        0000000000000000 006720 000016 00 AXG  0   0 16
[1814] .rela.text._ZN5folly17exception_wrapper7InPlaceINS_18FutureNoTimekeeperEE7delete_EPS0_ RELA            0000000000000000 eba9e8 000018 18  IG 5389 1813  8

function section数量减小 && 某些function section size增大，很容易就可以得到这次binary size的增大，可能是inline导致的。

在猜测可能是inline导致的问题之后，这里首先禁掉所有与inline相关的optimization flags。binary size从273M降低到了267M，也就是inline给binary size的增加带来了一定的影响，但并不是决定性的影响。

CXX_FLAGS="-O2" --> CXX_FLAGS="-fno-indirect-inlining -fno-partial-inlining -fno-inline-small-functions  -fno-inline-functions -fno-inline-functions-called-once -O2"

# default option
▶ readelf -WS Future.cpp.o| grep ".text.*" |  wc -l
16210
# add -O2 option
▶ readelf -WS Future.cpp.o| grep ".text.*" |  wc -l
3260
# add -O2 && -fno-indirect-inlining -fno-partial-inlining -fno-inline-small-functions  -fno-inline-functions -fno-inline-functions-called-once 
▶ readelf -WS Future.cpp.o| grep ".text.*" |  wc -l
4820

# add -O2 && -fno-indirect-inlining -fno-partial-inlining -fno-inline-small-functions  -fno-inline-functions -fno-inline-functions-called-once -fno-inline -fno-devirtualize-speculatively -fno-devirtualize
▶ readelf -WS Future.cpp.o| grep ".text.*" |  wc -l
14417

禁掉inline相关的flags，但是function sections的数量从3260增加到4820，但是离最初的16210还差了很多。所以应该还有其它的对binary size起决定性作用的flag。我后面显示加了-fno-inline，-fno-devirtualize-speculatively以及-fno-devirtualize（后者会基于类型信息，把virutal call转变为direct call，从而enable更多的inline），binary size继续从267M降低到了209M，依次添加这个选项，binary size呈递减状态。

可见经过我不停地尝试，binary size逐渐下降，同时function sections的个数也逐渐回升。但是这样不停尝试过之后发现，gcc的optimization flags相互交叉，相互影响，比我预想的要复杂很多。遂放弃尝试，最后发现真正决定binary size的不是-O2中某个单一的flag，而是一组flag，但虽然不是某个flag起作用，但是终归还是和inline有关系。

2.1 开启了-O2和-ffunction-sections的object file中.text section存放了什么内容？

但是最终还有一个小疑问，对于一个elf object file来说，使用-ffunction-sections时，所有函数都有对应的function section，为什么还有一个单独的.text段，它存储的是什么内容？

为了搞清楚这一点，使用下面的命令把Future.cpp.o中.text的内容打印出来。

objdump -dj .text Future.cpp.o

发现-O2 option的版本和不加-O2的版本的内容相差很多。对于添加了-O2 option的版本，有很多有.irsa.number，.part.number和.constprop.1521作为后缀的代码片段，所以：

irsa等代表了什么
为什么这部分代码会放到了.text段，而不是单独的function sections段中。

<_ZNK5folly7futures6detail10FutureBaseISt5tupleIJNS_3TryIdEENS4_INS_4UnitEEEEEE16throwIfContinuedEv.isra.393>
// ...
<_ZNK5folly7futures6detail10FutureBaseISt5tupleIJNS_3TryIbEENS4_INS_4UnitEEEEEE16throwIfContinuedEv.isra.369>
// ...

_ZN5folly7futures6detail4CoreINS_4UnitEE13detachPromiseEv.part.618
// ...
_ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EEC2IN5folly6fibers5BatonESaIS6_EJEEERPT_St20_Sp_alloc_shared_tagIT0_EDpOT1_.constprop.1521

关于isra
stackoverflow上有一个相关的为问题What is “isra” in the kernel thread dump 和 What does the GCC function suffix “isra” mean?，其中提到了一个optimization flag -fipa-sra，这个flag是-O2 option添加的。

-fipa-sra
Perform interprocedural scalar replacement of aggregates, removal of unused parameters and replacement of parameters passed by reference by parameters passed by value.
Enabled at levels -O2, -O3 and -Os.

从字面意思来理解，这个优化做的事情是过程间的聚合类型的标量替换，把pass-by-reference替换为pass-by-value，翻译成中文有点儿绕口。

// 这里没有必要传递一个传递指针进去，然后再对指针进行解引用。
static int foo(int *m)
{
  return *m + 1;
}

int bar(void)
{
  int i = 1;
  return foo(&i);
}

// 其实可以优化成下面的样子，这种是中间态，我没有找到合适的option来切实得到下面的转换
static int foo(int m)
{
  return m + 1;
}

int bar(void)
{
  int i = 1;
  return foo(i);
}

注：上图示例来自于Interprocedural optimization in GCC

关于.part
关于part，stackoverflow上也有相关的问题C++ function name demangling: What does this name suffix mean?，这个也和-O2中的另外一个flag相关，也就是-fpartial-inlining。~~某个函数可能太大~~ (partial inlining主要是为了解决hot/code code的问题，以最大限度利用L1I cache，避免frontend store)，不能直接inline，所以将函数的一部分进行inline，这一部分就单独拆分出来，通过mangled name加上.part后缀表示这个要被inline的子部分。

关于constprop
关于constprop，也有一个相关的问题What does the GCC function suffix .constprop mean?。可以看出来这个constprop，是和constant propagation相关的，从 https://github.com/gcc-mirror/gcc/blob/master/gcc/ipa-cp.c#L381 也得到了印证，虽然这个代码的细节我还没有时间看。

所以现在就可以回答“为什么在给定ffunction-sections的情况下，.text段还有如此之多code？”的问题了，因为添加了-O2选项，可能会对很多函数做优化，这些优化可能需要对函数进行某些变换，此时就需要在记录这些函数的“变化”版本。

三、结论

此次folly加-O2变大的主要原因是inline，但不是某一个inline flag导致的，而是多个优化flag综合在一起的作用。

四、学到的

gcc -O2 option会添加哪些优化flag
inline相关的option有哪些？
size的text值是怎么计算的
-ffunction-sections和-Wl,--gc-sections是什么
.text段中有很多mangled name有.irsa，.part和.constprop，它们是什么意思

这里WWDC 2019的视频What’s New in Clang and LLVM在介绍-Oz时给出的一个图。另外一个相关的问题就是-O3真的很快吗？为什在不了解你的应用时，不要轻易使用-O3？
在这里插入图片描述

注：上图来源于https://developer.apple.com/videos/play/wwdc2019/409/

参考
使用的工具，文档列表。

size
readelf
http://www.keil.com/support/man/docs/armclang_intro/armclang_intro_fnb1472741490155.htm
https://stackoverflow.com/questions/31227153/size-and-objdump-report-different-sizes-for-the-text-segment
https://www.gabriel.urdhr.fr/2015/09/28/elf-file-format/
https://linux-audit.com/elf-binaries-on-linux-understanding-and-analysis/
https://elinux.org/Function_sections
https://lwn.net/Articles/741494/
http://www.skyfree.org/linux/references/ELF_Format.pdf
https://static.lwn.net/images/conf/rtlws-2011/proc/Yong.pdf
https://kristerw.blogspot.com/2017/05/interprocedural-optimization-in-gcc.html
http://sciencewise.info/media/pdf/1010.2196v2.pdf
https://docs.google.com/presentation/u/1/d/1-K0ahFIAip12TJxAPJtQCpxZ4l6l19MneQMmKPQ-SjQ/htmlpresent
https://github.com/gcc-mirror/gcc/blob/master/gcc/ipa-cp.c#L381
https://stackoverflow.com/questions/14796686/what-does-the-gcc-function-suffix-constprop-mean
https://interrupt.memfault.com/blog/best-and-worst-gcc-clang-compiler-flags#the-best-and-worst-gcc-compiler-flags-for-embedded