优化屏障（Optimization barrier）第一讲

1. 编译优化导致编译器指令重排

要想理解Optimization barrier，先要理解Compiler Instruction Reorder，即编译器指令重排。
编译器指令重排是编译优化的结果，以gcc来说，它不知道为我们的代码默默做了多少事情，看看那整屏的优化选项就明了了。
本文以ubuntu下的gcc 4.4.3为实验，来逐步分析Optimization barrier的作用。
gcc的很多优化都可以造成指令重排，最常见的就是基本块重新排序（Basic block reordering）和指令调度（Instruction scheduling）。
为了解释Optimization barrier，我们只需要关注指令调度即可。

1.1 指令调度

首先看指令调度的作用:
http://www.lingcc.com/gccint/RTL-passes.html#RTL-passes
上关于指令调度的解释（可能因为是中文翻译，不一定精确）：

该过程寻找这样的指令，其输出在后来的指令中不会用到。在RISC机器上，内存加载和浮点指令经常会有这样的特征。它重新排序基本块中的指令以尝试将定义和使用分开，从而避免引起流水线阻塞。该过程执行两次，分别在寄存器分配之前和之后。该过程位于haifa-sched.c, sched-deps.c, sched-ebb.c, sched-rgn.c和sched-vis.c中。

实际编译选项中，这两个过程分别对应：-fschedule-insns和-fschedule-insns2

1）-fschedule-insns

如果对目标机支持这个功能,它试图重新排列指令,以便消除因数据未绪造成的执行停顿.这可以帮助浮点运算或内存访问 较慢的机器调取指令,允许其他指令先执行,直到调取指令或浮点运算完成.

2）-fschedule-insns2

类似于`-fschedule-insns’选项,但是在寄存器分配完成后,需要一个额外的指令调度过程.对于 寄存器数目相对较少,而且取内存指令大于一个周期的机器,这个选项特别有用.

下面以一个例子说明(该例子不知道摘自哪篇关于内存屏障的论文中)：

volatile int ready;
int message[100];

void no_cmb ( int i) {
 message[i/10] = 42;
 ready = 1;
}

首先，不优化之，即gcc -S cmb.c -o cmb_no_opt.s

.globl no_cmb
 .type no_cmb, @function
no_cmb:
 pushl %ebp
 movl %esp, %ebp
 movl 8(%ebp), %ecx
 movl $1717986919, %edx
 movl %ecx, %eax
 imull %edx
 sarl $2, %edx
 movl %ecx, %eax
 sarl $31, %eax
 movl %edx, %ecx
 subl %eax, %ecx
 movl %ecx, %eax
 movl $42, message(,%eax,4)
 movl $1, ready
 popl %ebp
 ret

可以看到，不优化的no_cmb函数中，是保持的原有的代码序的.
至于为什么i/10的汇编代码为什么是这个样子，可以参照别人的一篇博客http://blog.csdn.net/mathe/article/details/1153575

分别以-fschedule-insns和-fschedule-insns2优化之，如下：
1) gcc -S -fschedule-insns cmb.c -o cmb.s

.globl no_cmb
 .type no_cmb, @function
no_cmb:
 pushl %ebp
 movl %esp, %ebp
 movl 8(%ebp), %ecx
 movl $1717986919, %edx
 movl $1, ready
 movl %ecx, %eax
 imull %edx
 movl %ecx, %eax
 sarl $31, %eax
 sarl $2, %edx
 movl %edx, %ecx
 subl %eax, %ecx
 movl %ecx, %eax
 movl $42, message(,%eax,4)
 popl %ebp
 ret

2) gcc -S -fschedule-insns2 cmb.c -o cmb2.s

.globl no_cmb
 .type no_cmb, @function
no_cmb:
 pushl %ebp
 movl %esp, %ebp
 movl 8(%ebp), %ecx
 movl $1717986919, %edx
 movl %ecx, %eax
 imull %edx
 sarl $2, %edx
 movl %ecx, %eax
 sarl $31, %eax
 movl %edx, %ecx
 subl %eax, %ecx
 movl %ecx, %eax
 movl $42, message(,%eax,4)
 movl $1, ready
 popl %ebp
 ret

可以看到，-fschedule-insns2对no_cmb函数看不到效果，而-fschedule-insns使no_cmb代码发生的重排，ready = 1被排到message[i/10] = 42之前了。
为什么-fschedule-insns会有这样的效果呢？我们再来回顾一下它的功能：

它试图重新排列指令,以便消除因数据未绪造成的执行停顿

no_cmb函数中只包含两条语句:

message[i/10] = 42;
ready = 1;

其中message[i/10]相关的指令比较多，而ready相关的指令只有一条，我们知道，CPU处理指令都是
流水进行的，无依赖不冲突的指令可以并行处理，因为对应的执行单元是空闲的，而message[i/10]相关的指令都是有依赖的，不能够乱序执行，故将ready=1排在前面，优化CPU的流水处理。如果不这么做，可能CPU就将浪费数个指令周期来完成ready=1的操作了。这么看来，这个优化还是做对了。

2. 为了防止编译器指令重排

回过头来看看ready变量的类型，不错，的确是volatile的。

2.1 volatile让人费解的语义

volatile这个玩意儿的确很容易让人误解，以下几种场景就是大家对volatile理解的缩影：
1）volatile修饰的变量，每次读写都直接访存；
2）volatile像是gcc优化的局部开关，对于volatile修饰的变量，不对其进行优化；

两种理解都不是完全正确的，不过大体方向上的指引也没什么偏斜，知识的表达往往就是这样：能够指引正确方位的知识就是有作用的，更加精确的解释，可能需要花费更多的精力和篇章，结果更为复杂，学习它的人反而更难以接受，所以，更加精确的解释，需要学习它的人自己去领悟和摸索。
有点扯多了，我们来看volatile的第二条理解，既然volatile修饰的变量是不做优化的，那为什么还会将ready=1排到前面去呢？其实可以这样来理解：不是将ready=1排到前面，而是将message[i/10]较复杂的指令序列排到后面，这样就没有违反这个概念了。

就因为volatile这么容易让人误解，对代码重排也做不到足够的控制，非常多的人宣扬volatile在多线程编程中无用论。

2.2 采用编译器内存屏障来解决代码重排的问题

现在问题就来了，原本ready变量采用volatile变量，意图很明显，是想保证ready=1和message[i/10]=42对应指令的有序性，结果，代码优化后，结果却违反了意图。
那么，为了达到这个目标，gcc总应该提供一种方法吧。

面包会有的，方法也会有的：

gcc提供了内联汇编的语句可以做到这一点：

asm volatile ( "" ::: "memory" );
// or
__asm__ __volatile__ ( "" ::: "memory" );

这即是本文主要想说明的Optimization barrier.

先看其能否解决ready的问题：
先在两句中插入Optimization barrier，则代码如下：

volatile int ready;
int message[100];

void cmb ( int i) {
 message[i/10] = 42;
 __asm__ __volatile__ ( "" ::: "memory" );
 ready = 1;
}

同样以gcc -S -fschedule-insns cmb.c -o cmb.s编译之：

.globl cmb
 .type cmb, @function
cmb:
 pushl %ebp
 movl %esp, %ebp
 movl 8(%ebp), %ecx
 movl $1717986919, %edx
 movl %ecx, %eax
 imull %edx
 movl %ecx, %eax
 sarl $31, %eax
 sarl $2, %edx
 movl %edx, %ecx
 subl %eax, %ecx
 movl %ecx, %eax
 movl $42, message(,%eax,4)
 movl $1, ready
 popl %ebp
 ret

OK，发现顺序正确了，而且居然没有新增指令，这是怎么回事呢？__asm__ __volatile__ (“” ::: “memory”)跑哪里去了。