MySQL编译选项 -fno-strict-aliasing随手记

最近发布的MySQL8.0.2版本中，将gcc的编译选项从--fno-strict-aliasing移除，也就是说打开strict aliasing, 根据worklog #10344 的描述，在单线程的性能测试中，有最多%4的性能提升，还是相当可观的。这个flag在我们内部编译版本中也是一直打开的，但一直不知甚解。本文是网上搜索文档和自己试验的小结。

首先strict aliasing是个什么鬼？ --fno-strict-aliasing对应的是--f-strict-aliasing，GCC文档的解释如下：

Allow the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same. For example, an unsigned int can alias an int, but not a void* or a double. A character type may alias any other type.

Stackoverflow上关于strict aliasing规则的问题

当使用strict aliasing时， 编译器会认为在不同类型之间的转换不会发生，因此执行更激进的编译优化，例如reorder执行顺序。

Strcit aliasing只能隐式的开启或者显式的禁止掉。在-o2或更高的编译级别上会被隐式开启。

这里举个简单的例子，参考网络 上这篇文章

$cat x.c
#include <stdio.h>
#include <stdint.h>

int main()
{
        int a = 0x12345678;

        uint16_t* const sp = (uint16_t*)&a;
        uint16_t hi = sp[0];
        uint16_t lo = sp[1];

        sp[1] = hi;
        sp[0] = lo;

        printf("%x\n", a);

        return 0;
}

函数的功能很简单，对一个数字的高低位进行交换

gcc版本

$gcc --version
gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)

执行strict aliasing （O2及以上默认打开）

$gcc -O2  x.c

$./a.out
12345678

非strict aliasing (显式指定-fno-strict-aliasing)

$gcc -O2 -fno-strict-aliasing x.c

$./a.out
56781234

不同的gcc flag，两次的执行结果居然完全不相同，只有第二次才实现了预期功能。因为默认情况下不报warning，我们把告警打开看看：

$gcc -O2 -Wstrict-aliasing x.c
x.c: In function ‘main’:
x.c:13: warning: dereferencing pointer ‘sp’ does break strict-aliasing rules
x.c:9: warning: dereferencing pointer ‘sp’ does break strict-aliasing rules
x.c:8: note: initialized from here
x.c:10: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules
x.c:10: note: initialized from here
x.c:12: warning: dereferencing pointer ‘({anonymous})’ does break strict-aliasing rules
x.c:12: note: initialized from her

果然在使用strict aliasing时，因为破坏了严格aliasing的规则大量报警，因此如果我们要使用strict aliasing，一定要打开报警，并重视每个warning。

回到刚才的问题，为什么strict aliasing会输出最原始的数据，而不是修改后的数据呢 ？ 看起来就好像后面的修改全部被忽略掉了一样。 我们来看看编译后的代码。可以看到两个汇编代码完全不相同。编译器认为代码里不可能出现不规范的类型转换，所以在错误的案例里，a的未被修改的值被直接抛给了printf函数

正确的 (gcc -O2 -fno-strict-aliasing x.c)

(gdb) disassemble main
Dump of assembler code for function main:
   0x00000000004004d0 <+0>:     sub    $0x18,%rsp
   0x00000000004004d4 <+4>:     mov    $0x4005f8,%edi
   0x00000000004004d9 <+9>:     xor    %eax,%eax
   0x00000000004004db <+11>:    movw   $0x5678,0xe(%rsp)
   0x00000000004004e2 <+18>:    movw   $0x1234,0xc(%rsp)
   0x00000000004004e9 <+25>:    mov    0xc(%rsp),%esi
   0x00000000004004ed <+29>:    callq  0x4003b8 <printf@plt>
   0x00000000004004f2 <+34>:    xor    %eax,%eax
   0x00000000004004f4 <+36>:    add    $0x18,%rsp
   0x00000000004004f8 <+40>:    retq
End of assembler dump.

错误的 (gcc -O2 -fstrict-aliasing x.c)

(gdb) disassemble main
Dump of assembler code for function main:
   0x00000000004004d0 <+0>:     sub    $0x18,%rsp
   0x00000000004004d4 <+4>:     mov    $0x12345678,%esi
   0x00000000004004d9 <+9>:     mov    $0x4005f8,%edi
   0x00000000004004de <+14>:    xor    %eax,%eax
   0x00000000004004e0 <+16>:    movw   $0x5678,0xe(%rsp)
   0x00000000004004e7 <+23>:    movw   $0x1234,0xc(%rsp)
   0x00000000004004ee <+30>:    callq  0x4003b8 <printf@plt>
   0x00000000004004f3 <+35>:    xor    %eax,%eax
   0x00000000004004f5 <+37>:    add    $0x18,%rsp
   0x00000000004004f9 <+41>:    retq
End of assembler dump.

但是如果我换成高版本的gcc，例如4.8版本，两种编译方式都没有问题，甚至加上-Wstrict-aliasing连报警都没有。只有加上-Wstrict-aliasing=1才报warning

$/opt/rh/devtoolset-2/root/usr/bin/gcc --version
gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)

$/opt/rh/devtoolset-2/root/usr/bin/gcc -O2 -fno-strict-aliasing x.c

$./a.out
56781234

/opt/rh/devtoolset-2/root/usr/bin/gcc -O2 -fstrict-aliasing x.c

$./a.out
56781234

$/opt/rh/devtoolset-2/root/usr/bin/gcc -O2 -fstrict-aliasing -Wstrict-aliasing=1 x.c
x.c: In function ‘main’:
x.c:9:2: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing]
  uint16_t* const sp = (uint16_t*)&a;

网上搜了一下，Stackoverflow上有一些类似的问题 1， 2。 我理解这应该是gcc编译器的高版本对类型转换规则的识别可能做的更加好，细节不太了解，如有看到这篇文章的朋友，求帮忙修正 :)

！！！无论如何， 如果你需要打开strict aliasing, 一定要打开Wstrict-aliasing，消除代码warning。 同时在代码上也要尽量减少这种不同类型的转换。

在MySQL移除-fno-strict-aliasing后， 也看到了一些担忧，因为mysql的codebase毕竟已经相当古老了， 而当前并没有一些静态或动态的分析工具能够找到所有违反strict aliasing规则的地方。可能存在潜在的风险。