乱序优化与GCC的bug

 

以下内容来自搜狗实验室技术交流文档，搜狐公司研发中心版权所有，仅供技术交流

 

摘要

---------

乱序优化是现代编译器非常重要的特性，本文介绍了什么是乱序优化，以及由此引发的一个bug，希望引起各位开发者的注意。

 

乱序优化

---------

乱序优化和cpu的乱序执行很类似。

现代cpu都采用流水线结构，流水线的各级可以同时执行不同的指令，也只有用多条指令将流水线填满以后，cpu的能力才能得到充分发挥。

乱序执行（out-of-order execution）是指cpu允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理的技术。这样将根据各个电路单元的状态和各指令能否提前执行的具体情况分析后，将能提前执行的指令立即发送给相应电路单元执行，在这期间不按规定顺序执行指令，然后由重新排列单元将各执行单元结果按指令顺序重新排列。采用乱序执行技术的目的是为了使cpu内部电路满负荷运转并相应提高了cpu的运行程序的速度。

由于cpu流水线的指令预取范围有限，所以只能在很小的范围内判断指令是否能够并发，如果相隔比较远的指令才可以并发就无能为力了。编译器可以分析相当长的一段代码从而把能够并发的代码经量靠近，这就是所谓的乱序优化。

乱序优化的关键在于编译器能够正确的识别哪些代码能够并发，如果发生误判就会导致不可预见的bug。一般情况下都没有问题--但是如果你写出一些太过诡异的代码就很难讲了。

 

来看一个优化错误实例程序:

buggy.c

#include <stdio.h>
#include <stdlib.h>

typedef unsigned short UINT16;
typedef unsigned int UINT32；

struct EndPoint{
    UINT16 tcpPort_;
    UINT16 udpPort_;
    //UINT32 ipAddress_;
};

inline UINT32 EndPointToUInt32(struct EndPoint* ep){
    return *(const UINT32*)(ep); //buug here
}

struct EndPoint endpoint = {0x8080, 0x1080};

int main()
{
    //下句在inline+乱序优化时出错
    endpoint.udpPort_ = 0;
    
    UINT32 tmp2 = EndPointToUInt32(&endpoint);
    //UINT32 tmp2 = *(const UINT32*)(&endpoint); //用这一句替换上一句同样出错
    srand(tmp2); // for break the optimize
    printf("%08x %08x should be same as 00008080\n", tmp2, EndPointToUInt32(&endpoint));
}

运行结果如下：

gcc buggy.c

./a.out

00008080 00008080 should  be same as 00008080

gcc -O2 buggy.c

./a.out

10808080 00008080 should be same as 00008080

可以看到打开优化之后EndPointToUInt32这个函数的第一次执行就不正常了。

 

分析

---------

粗略的分析一下目标码

gcc直接编译的结果	替换掉函数调用后的结果	gcc -o2编译的结果
movw $0,endpoint+2	movw $0,endpoint+2	movl endpoint,%ebx
pushl $endpoint	movl endpoint,%eax	subl $28,%esp
call EndPiontToUInt32	movl %eax,-4(%ebp)	pushl %ebx
addl $4,%esp	subl $12,%esp	movw $0,endpoint+2
movl %esx,-4(%ebp)	pushl -4(%ebp)	call srand
subl $12,%esp	call srand	addl $12,%esp
pushl -4(%ebp)	addl $16,%esp	pushl endpoint
call srand	subl $4,%esp	pushl %ebx
addl %16,%esp	pushl $endpoint	pushl $.LC0
subl $4,%esp	call EndPointToUInt32	call printf
pushl $endpoint	addl $4,%esp
call EndPointToUInt32	pushl %eax
addl $4,%esp	pushl -4(%ebp)
pushl %eax	pushl $.LC0
pushl -4(%ebp)	call printf
pushl $.LC0
call printf

左边的是优化之前的代码，然后movw置endpoint的一半为0，然后取出endpoint的地址调用EndPointToUInt32，并把结果放到tmp2也就是-4(%ebp)中。

中间的代码是将函数inline化以后的结果，注意到现在直接把endpoint的内容通过%eax传给了tmp2也就是-4(%ebp)

右边的代码经过了-o2优化，首先做了一次inline操作，取消了对EndPointToUInt32的调用，也就是直接把endpoint的内容作为EndPointToUInt32的返回值来处理。其次，取消了tmp2变量，用%ebx来替代。至此都没有问题。

问题在于将movw $0,endpoint+2一句优化到了movl endpoint, %ebx的后面。这里做了一个错误的乱序优化。这是因为首先gcc没有能够正确的判断出*(const UINT32*)(&endpoint)实际上和endpoint.udpPort_是相关的，从而优化出错。本来这也是可以容忍的，毕竟写法太变态。但是gcc又在处理inline时过于冒进，没有按照真正的函数调用那样在函数调用处设置一个边界，阻止函数调用前后的代码混杂，而是像一个宏展开一样简单的处理了，最后导致了和预想不一致的结果。

 

结论

---------

gcc除少数版本外，在-o2乱序优化时都不够完善，不能正确判断代码的影响范围，从而做出错误的乱序。所以请不要引入一些编译器难以判断影响范围的语句，尤其是胡乱cast。典型的如上面程序中的*(const UINT32*)(ep);

gcc的乱序优化对inline函数是像宏展开一样处理的，这可能导致将函数和函数附近的代码乱序，需要小心，常用的FC3/FC5上的gcc都有此问题。