UID 1
精华
积分 76310
威望 点
宅币 个
贡献 次
宅之契约 份
最后登录 1970-1-1
在线时间 小时
gcc的链接时间优化(-flto -fuse-linker-plugin)是很强的优化(配合-O2或-O3),可以实现跨obj文件优化。也就是说,假设你的程序有foo.c和bar.c两个源码文件,你在foo.c里面写了一个简短函数,它可以被bar.c内联。
原理上gcc是在编译单个obj的时候,解析你的.c,记住你的逻辑,然后存为类似java、.net那样的字节码,并以“附加数据”的方式附加到obj(虽说是elf格式)中间文件里。在编译时间gcc只是读取你源码里面的逻辑部分,并没有生成实际的机器指令。这依然可以是一种节省编译时间的方案,因为解析源码需要先经过预处理,再解析各种名字长短不一的类型、变量或函数等。
在链接的时候,你要用gcc来链接,而不是ld。你同样需要把-O3 -flto -fuse-linker-plugin告诉给你的gcc,然后用-Xlinker去传递你的链接器参数,包括链接器脚本等。经过我的实际测试,我发现在开启了链接时间优化后,编译的速度大幅上升,而链接的速度并没有明显下降,并且优化的效果非常显著。我在使用gcc arm toolchain编译STM32程序的时候,它确实把STM32外设驱动提供的函数都内联了,并且删掉了多余的东西。
观察一个编译器优化效果的最好办法,就是直接看编译器输出的bin。我把链接后得到的elf丢进IDA以后,就可以直接看到它的逻辑了。那些标红 的部分,是代码里面通过直接写绝对地址来对外设寄存器进行操作的部分。这里面包括了清空.bss段、从ROM复制.data段到RAM的过程(这部分是我写的),以及SystemInit(); 内部的所有过程(升频、把频率值写到一个全局变量里给你看、以及对各种外设的初始化等)(这个就是STM32外设驱动带的东西了)。
为什么要进行链接时间优化呢?简要来说是以下的原因:在编译时间,编译器只知道当前obj里面的函数、变量等,不知道别的obj的情况。这导致优化的效果受到的局限性较大,因为编译器并不知道别的obj提供的函数是个什么情况。你调用别的obj的过程就像调用API那样,不得不按照调用约定来严格调用,这是保证代码可以正确运行的必要过程。
你写C的时候一定会把声明放到头文件,实现放到obj(.c)里面吧?对于编译器,万一你声明的这个函数所在的obj并不是用同一个编译器编译的呢?在这种情况下,调用约定统一了二进制接口,保证你可以把多个不同编译器生成的bin组装到一起(这就是所谓的“链接”了),来实现模块化开发。
然而实际的情况就是,你的编译器就是GCC,你用不着混合多个编译器来开发,而且你拥有你的每个模块的源码。
编译器无法做到跨文件的优化,对于全局变量、非static的空函数等(你也许觉得你肯定不会瞎写什么空函数),编译器并不能拿定主意决定要不要保留它,于是就都保留了。
. 你封装的模块,随着不断地升级、进化,有的函数被取缔,有的函数只做非常简单的赋值(比如初始化、各种属性set/get等,比如你的对象的构造、析构等。注意C语言也经常有这种情况)。为了兼容旧的调用者,那些被取缔的函数依然要保留,只不过它的实现部分啥都不做。
然而如果每次调用者都call/bl你的空函数,导致你的bin里面有各种call->ret、bl->bx lr(调用后直接返回),这难道不是很蠢嘛?“你妈叫你回家吃饭!” ->“你回来啦?我逗你的,你妈今晚在外面吃”
以及之前说的简单赋值,call->mov->ret无非多了些mov而已,还不如直接内联呢。然而跨obj了,对于编译器而言,它并不知道别的obj里面这函数只是几个mov和一个ret,所以依然还是老老实实地排列参数,并进行一次正式的函数调用。生活中太细节的东西就用不着这么讲究仪式感了吧,更何况这并不是“生活”。
. 然后你意识到这太蠢了。怎么办呢?你要自己亲自把这些简短的函数写成“宏函数”,比如 #define R G B (r ,g ,b ) ((((r) & 0xFF) << 16) |(((g) & 0xFF) << 8) |((b) & 0xFF) ) 这种样子的。或者,用inline 、static 等,然后在头文件 里定义这些函数的实现部分 。
我确实这么做过,结果仔细一想,我为啥非要自己判断我的函数会被编译器编译成什么样子呢?这难道不是编译器的工作嘛?事实上,在C++,很多的类构造和析构写起来都很简短(“无非搞了个局部变量嘛”),然而真正展开后,它还是复杂得吓人的,并且这类函数会因为过长而内联失败。
我还发现了一个严重的问题,那就是有的函数它最终被编译出来的指令还是非常长的,长到以至于不适合被内联。这还分两种情况,一种是我用#define实现了这个“函数”,另一种是我用inline、static等实现了这个函数。然而对于前者(#define的情况),它确实必定被“内联”(预处理器帮它强行内联),然而最终我得到的bin非常啰嗦、冗长。对于后者(inline或static的情况),如果一个函数太长,编译器“觉得”它不应该被内联的话,那我只要在obj里面调用了它,这个obj里面就会有这个函数的bin。那也就是说,我在多个obj里面调用这个被内联失败的函数的话,我就会得到多个这个函数的bin。这同样很蠢 ,你有几个obj你就有几个这种函数的副本,很多100 MB以上的exe我丢到IDA里面一看,确实就是这么一回事儿。
. 由于以上的特性,写Java、C#的人会得瑟,认为你很蠢。因为Java、C#生成的字节码可以在运行的时候进行JIT编译,这个过程就像一次全程序编译一样,可以让编译器进行全程序优化。
而且你要是写C的功底不够强,被各种指针问题、内存问题困扰的话,对方就更得瑟了。怎能如此丢脸呢?
. 那假设我把所有的函数实现都写到头文件里,然后我只有main.c(或main.cpp),它包含了所有头文件、所有函数的声明和实现,是不是就没有这些担忧了呢?
确实如此。
然而如果你的工程够大,编译一次你大概得花很久,这不是一杯咖啡两杯咖啡的问题,而是一边写,一边调试、编译的情况,你的耐心会被很快消磨殆尽,并且被挫败感充斥。
“兄弟你这里是不是忘了打一个分号啊?”
“哦对啊。卧槽,白等了一上午了。”
于是你默默地补了个分号,然后重新开始编译,并且在等了5小时后编译成功,并且它依然有各种各样的B U
G。看着这些代码,你大概是相当痛苦的。毕竟每次编译都要等5小时……
. 所以,有了链接时间优化的话,你就可以在不牺牲编译速度的情况下,实现全程序优化了。
完。
但你要注意,如果你要把你的现有工程改为使用链接时间优化的编译方式的话,你要把你的所有的写在头文件的inline宏函数,转移到一个obj里面,否则在链接时间,GCC会告诉你,你的各种obj文件都有这个函数,冲突了。不给你链接。
所以你要老老实实地把声明写到头文件,把实现写到obj(.c、.cpp等),然后祈祷链接时间优化带你超神吧。
顺带介绍一个。clang,llvm,是一款通过把C系源码编译为字节码,然后把字节码优化编译为bin,或者,直接JIT解释+编译运行字节码的平台以及工具集。据说很棒,值得一试。
参考资料:
编写快得像宏一样的内联函数
https
://gcc.gnu.org/on
linedocs/gcc/Inline.htm
l
GCC优化选项
ht
tps://gcc.gnu.org/on
linedocs/gcc/Optimi
ze-Options.html
注意看-flto的部分。
gcc ,
编译器 ,
优化 ,
链接 ,
编译原理 ,
gcc ,
gcc ,
gcc ,
gcc ,
gcc ,
gcc