Joh*_*nck 24 c optimization x86 assembly gcc
我正在编译这个C代码:
int mode; // use aa if true, else bb
int aa[2];
int bb[2];
inline int auto0() { return mode ? aa[0] : bb[0]; }
inline int auto1() { return mode ? aa[1] : bb[1]; }
int slow() { return auto1() - auto0(); }
int fast() { return mode ? aa[1] - aa[0] : bb[1] - bb[0]; }
两者slow()和fast()函数都是为了做同样的事情,尽管fast()它有一个分支语句而不是两个.我想检查GCC是否会将两个分支机构合并为一个分支机构.我已经尝试了GCC 4.4和4.7,具有各种级别的优化,如-O2,-O3,-Os和-Ofast.它总是给出同样奇怪的结果:
慢():
movl mode(%rip), %ecx
testl %ecx, %ecx
je .L10
movl aa+4(%rip), %eax
movl aa(%rip), %edx
subl %edx, %eax
ret
.L10:
movl bb+4(%rip), %eax
movl bb(%rip), %edx
subl %edx, %eax
ret
快速():
movl mode(%rip), %esi
testl %esi, %esi
jne .L18
movl bb+4(%rip), %eax
subl bb(%rip), %eax
ret
.L18:
movl aa+4(%rip), %eax
subl aa(%rip), %eax
ret
实际上,在每个函数中仅生成一个分支.然而,slow()似乎以一种令人惊讶的方式低劣:它在每个分支中使用一个额外的负载,用于aa[0]和bb[0].该fast()代码使用它们直接从在存储器subl•不用它们加载到寄存器中第一个.因此slow()每次调用使用一个额外的寄存器和一个额外的指令
一个简单的微基准测试表明,调用fast()10亿次需要0.7秒,而1.1秒slow().我在2.9 GHz使用Xeon E5-2690.
为什么会这样？你能不能以某种方式调整我的源代码,以便GCC做得更好？
编辑:以下是Mac OS上clang 4.2的结果:
慢():
movq _aa@GOTPCREL(%rip), %rax ; rax = aa (both ints at once)
movq _bb@GOTPCREL(%rip), %rcx ; rcx = bb
movq _mode@GOTPCREL(%rip), %rdx ; rdx = mode
cmpl $0, (%rdx) ; mode == 0 ?
leaq 4(%rcx), %rdx ; rdx = bb[1]
cmovneq %rax, %rcx ; if (mode != 0) rcx = aa
leaq 4(%rax), %rax ; rax = aa[1]
cmoveq %rdx, %rax ; if (mode == 0) rax = bb
movl (%rax), %eax ; eax = xx[1]
subl (%rcx), %eax ; eax -= xx[0]
快速():
movq _mode@GOTPCREL(%rip), %rax ; rax = mode
cmpl $0, (%rax) ; mode == 0 ?
je LBB1_2 ; if (mode != 0) {
movq _aa@GOTPCREL(%rip), %rcx ; rcx = aa
jmp LBB1_3 ; } else {
LBB1_2: ; // (mode == 0)
movq _bb@GOTPCREL(%rip), %rcx ; rcx = bb
LBB1_3: ; }
movl 4(%rcx), %eax ; eax = xx[1]
subl (%rcx), %eax ; eax -= xx[0]
有趣的是:clang为slow()一个分支生成无分支条件fast()!另一方面,slow()三个负载(其中两个是推测性的,一个是不必要的)与两个负载相比fast().该fast()实施更为"明显",并与GCC它的短,少使用一个寄存器.
Mac OS上的GCC 4.7通常会遇到与Linux相同的问题.然而它在Mac OS上使用相同的"加载8字节然后两次提取4字节"模式作为Clang.这有点令人感兴趣,但不是很相关,因为在sublGCC的任一平台上发射两个寄存器而不是一个存储器和一个寄存器的原始问题是相同的.
chi*_*ill 22
原因是在初始中间代码中,为slow()内存加载和减法发出的是不同的基本块:
slow ()
{
int D.1405;
int mode.3;
int D.1402;
int D.1379;
# BLOCK 2 freq:10000
mode.3_5 = mode;
if (mode.3_5 != 0)
goto <bb 3>;
else
goto <bb 4>;
# BLOCK 3 freq:5000
D.1402_6 = aa[1];
D.1405_10 = aa[0];
goto <bb 5>;
# BLOCK 4 freq:5000
D.1402_7 = bb[1];
D.1405_11 = bb[0];
# BLOCK 5 freq:10000
D.1379_3 = D.1402_17 - D.1405_12;
return D.1379_3;
}
而在fast()它们处于相同的基本块中:
fast ()
{
int D.1377;
int D.1376;
int D.1374;
int D.1373;
int mode.1;
int D.1368;
# BLOCK 2 freq:10000
mode.1_2 = mode;
if (mode.1_2 != 0)
goto <bb 3>;
else
goto <bb 4>;
# BLOCK 3 freq:3900
D.1373_3 = aa[1];
D.1374_4 = aa[0];
D.1368_5 = D.1373_3 - D.1374_4;
goto <bb 5>;
# BLOCK 4 freq:6100
D.1376_6 = bb[1];
D.1377_7 = bb[0];
D.1368_8 = D.1376_6 - D.1377_7;
# BLOCK 5 freq:10000
return D.1368_1;
}
GCC依赖于指令组合传递来处理这样的情况(即显然不是在窥视孔优化传递上)并且组合工作在基本块的范围上.这就是为什么减法和载荷组合在一个insn中fast()并且它们甚至不被考虑用于组合slow().
之后,在基本块重新排序过程中,减法输入slow()被复制并移动到包含负载的基本块中.现在组合器有机会将加载和减法结合起来,但遗憾的是,组合器传递不会再次运行(并且可能在编译过程的后期无法运行,并且已经分配了硬件寄存器和东西).
我没有答案为什么GCC无法按照您希望的方式优化代码,但我有办法重新组织您的代码以实现类似的性能.相反,组织代码,你这样做的方式slow()还是fast(),我建议你定义返回要么是内联函数aa或bb基于mode而不需要一个分支:
inline int * xx () { static int *xx[] = { bb, aa }; return xx[!!mode]; }
inline int kwiky(int *xx) { return xx[1] - xx[0]; }
int kwik() { return kwiky(xx()); }
由GCC 4.7编译时-O3:
movl mode, %edx
xorl %eax, %eax
testl %edx, %edx
setne %al
movl xx.1369(,%eax,4), %edx
movl 4(%edx), %eax
subl (%edx), %eax
ret
根据定义xx(),您可以重新定义auto0()并auto1()喜欢:
inline int auto0() { return xx()[0]; }
inline int auto1() { return xx()[1]; }
而且,从此,您应该看到slow()现在编译成类似或相同的代码kwik().