在编写优化的ftol函数时，我在GCC 4.6.1中发现了一些非常奇怪的行为。让我先向您展示代码（为清楚起见，我标记了差异）：
fast_trunc_one，C：
int fast_trunc_one(int i) {
int mantissa, exponent, sign, r;
mantissa = (i & 0x07fffff) | 0x800000;
exponent = 150 - ((i >> 23) & 0xff);
sign = i & 0x80000000;
if (exponent < 0) {
r = mantissa << -exponent; /* diff */
} else {
r = mantissa >> exponent; /* diff */
}
return (r ^ -sign) + sign; /* diff */
}
fast_trunc_two，C：
int fast_trunc_two(int i) {
int mantissa, exponent, sign, r;
mantissa = (i & 0x07fffff) | 0x800000;
exponent = 150 - ((i >> 23) & 0xff);
sign = i & 0x80000000;
if (exponent < 0) {
r = (mantissa << -exponent) ^ -sign; /* diff */
} else {
r = (mantissa >> exponent) ^ -sign; /* diff */
}
return r + sign; /* diff */
}
似乎一样吗？ GCC不同意。使用gcc -O3 -S -Wall -o test.s test.c进行编译后，这是程序集输出：
fast_trunc_one，生成：
_fast_trunc_one:
LFB0:
.cfi_startproc
movl 4(%esp), %eax
movl $150, %ecx
movl %eax, %edx
andl $8388607, %edx
sarl $23, %eax
orl $8388608, %edx
andl $255, %eax
subl %eax, %ecx
movl %edx, %eax
sarl %cl, %eax
testl %ecx, %ecx
js L5
rep
ret
.p2align 4,,7
L5:
negl %ecx
movl %edx, %eax
sall %cl, %eax
ret
.cfi_endproc
fast_trunc_two，生成：
_fast_trunc_two:
LFB1:
.cfi_startproc
pushl %ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
movl 8(%esp), %eax
movl $150, %ecx
movl %eax, %ebx
movl %eax, %edx
sarl $23, %ebx
andl $8388607, %edx
andl $255, %ebx
orl $8388608, %edx
andl $-2147483648, %eax
subl %ebx, %ecx
js L9
sarl %cl, %edx
movl %eax, %ecx
negl %ecx
xorl %ecx, %edx
addl %edx, %eax
popl %ebx
.cfi_remember_state
.cfi_def_cfa_offset 4
.cfi_restore 3
ret
.p2align 4,,7
L9:
.cfi_restore_state
negl %ecx
sall %cl, %edx
movl %eax, %ecx
negl %ecx
xorl %ecx, %edx
addl %edx, %eax
popl %ebx
.cfi_restore 3
.cfi_def_cfa_offset 4
ret
.cfi_endproc
这是极端的差异。这实际上也显示在个人资料中，fast_trunc_one比fast_trunc_two快30％左右。现在我的问题是：是什么导致了这个问题？
答案 0 :(得分：254)
已更新以与OP的编辑同步
通过修改代码，我已经设法看到GCC如何优化第一种情况。
在我们理解为何如此不同之前，首先我们必须了解GCC如何优化fast_trunc_one()。
信不信由你，fast_trunc_one()正在优化：
int fast_trunc_one(int i) {
int mantissa, exponent;
mantissa = (i & 0x07fffff) | 0x800000;
exponent = 150 - ((i >> 23) & 0xff);
if (exponent < 0) {
return (mantissa << -exponent); /* diff */
} else {
return (mantissa >> exponent); /* diff */
}
}
这会生成与原始fast_trunc_one()完全相同的程序集 - 注册名称和所有内容。
请注意xor的程序集中没有fast_trunc_one()个。这就是让我离开的原因。
第1步： sign = -sign
首先，我们来看看sign变量。自sign = i & 0x80000000;起，sign只能有两个可能的值：
sign = 0 sign = 0x80000000 现在认识到两种情况都是sign == -sign。因此，当我将原始代码更改为：
int fast_trunc_one(int i) {
int mantissa, exponent, sign, r;
mantissa = (i & 0x07fffff) | 0x800000;
exponent = 150 - ((i >> 23) & 0xff);
sign = i & 0x80000000;
if (exponent < 0) {
r = mantissa << -exponent;
} else {
r = mantissa >> exponent;
}
return (r ^ sign) + sign;
}
它生成与原始fast_trunc_one()完全相同的程序集。我会给你免费的装配，但它是相同的 - 注册名称和所有。
第2步：数学减少：x + (y ^ x) = y
sign只能使用0或0x80000000这两个值中的一个。
x = 0时，x + (y ^ x) = y然后琐碎。0x80000000添加和xoring是相同的。它翻转了标志位。因此，x + (y ^ x) = y时，x = 0x80000000也会成立。因此，x + (y ^ x)缩减为y。代码简化了这个：
int fast_trunc_one(int i) {
int mantissa, exponent, sign, r;
mantissa = (i & 0x07fffff) | 0x800000;
exponent = 150 - ((i >> 23) & 0xff);
sign = i & 0x80000000;
if (exponent < 0) {
r = (mantissa << -exponent);
} else {
r = (mantissa >> exponent);
}
return r;
}
同样，这将编译为完全相同的程序集 - 注册名称和所有。
以上版本最终简化为：
int fast_trunc_one(int i) {
int mantissa, exponent;
mantissa = (i & 0x07fffff) | 0x800000;
exponent = 150 - ((i >> 23) & 0xff);
if (exponent < 0) {
return (mantissa << -exponent); /* diff */
} else {
return (mantissa >> exponent); /* diff */
}
}
这几乎就是GCC在装配中生成的内容。
那么为什么编译器不能将fast_trunc_two()优化为同一个东西呢？
fast_trunc_one()中的关键部分是x + (y ^ x) = y优化。在fast_trunc_two()中，x + (y ^ x)表达式在分支中被拆分。
我怀疑这可能足以让GCC混淆不进行优化。 （它需要将^ -sign提升出分支并将其合并到最后的r + sign。）
例如，这会生成与fast_trunc_one()相同的程序集：
int fast_trunc_two(int i) {
int mantissa, exponent, sign, r;
mantissa = (i & 0x07fffff) | 0x800000;
exponent = 150 - ((i >> 23) & 0xff);
sign = i & 0x80000000;
if (exponent < 0) {
r = ((mantissa << -exponent) ^ -sign) + sign; /* diff */
} else {
r = ((mantissa >> exponent) ^ -sign) + sign; /* diff */
}
return r; /* diff */
}
答案 1 :(得分：64)
这是编译器的本质。假设他们将采取最快或最好的路径，是非常错误的。任何暗示您不需要对代码进行任何操作以进行优化的人，因为＆＃34;现代编译器＆＃34;填补空白，做最好的工作，制作最快的代码，等等。实际上我看到gcc从3.x到4.x在手臂上变得更糟。到目前为止，4.x可能已达到3.x，但在早期它会产生较慢的代码。通过练习，您可以学习如何编写代码，这样编译器就不必努力工作，从而产生更一致和预期的结果。
这里的错误是你对将要制作的东西的期望，而不是实际产生的东西。如果希望编译器生成相同的输出，请为其输入相同的输入。不是数学上相同，不是有点相同，但实际上是相同的，没有不同的路径，没有从一个版本到另一个版本的共享或分发操作。这是一个很好的练习，可以理解如何编写代码并查看编译器使用它做什么。不要错误地假设因为一天的一个处理器目标的一个版本的gcc产生了一定的结果，这是所有编译器和所有代码的规则。你必须使用许多编译器和许多目标来了解正在发生的事情。
gcc非常讨厌，我邀请你看看幕后，看看gcc的内脏，尝试添加一个目标或自己修改一些东西。它几乎没有用胶带和捞丝固定在一起。在关键位置添加或删除了一行额外的代码，它崩溃了。事实上它已经产生了可用的代码，这是令人高兴的事情，而不是担心为什么它没有满足其他期望。你看过gcc的不同版本产生了什么？ 3.x和4.x特别是4.5 vs 4.6 vs 4.7等？对于不同的目标处理器，x86，arm，mips等或x86的不同风格，如果这是你使用的本机编译器，32位vs 64位等？然后llvm（clang）针对不同的目标？
Mystical在完成分析/优化代码问题所需的思考过程中做得非常出色，希望编译器能够提出任何一个，而不是任何＆＃34;现代编译器＆ ＃34;
没有进入数学属性，这种形式的代码
if (exponent < 0) {
r = mantissa << -exponent; /* diff */
} else {
r = mantissa >> exponent; /* diff */
}
return (r ^ -sign) + sign; /* diff */
将引导编译器到A：以该形式实现它，执行if-then-else然后收敛于公共代码以完成并返回。或者B：保存分支，因为这是函数的尾部。也不用担心使用或保存r。
if (exponent < 0) {
return((mantissa << -exponent)^-sign)+sign;
} else {
return((mantissa << -exponent)^-sign)+sign;
}
然后你可以进入，因为Mystical指出sign符号变量一起消失所有代码所写的。我不希望编译器看到符号变量消失所以你应该自己完成，而不是强迫编译器试图解决它。
这是深入了解gcc源代码的绝佳机会。看来你已经找到了一个案例，优化器在一个案例中看到了一件事，在另一个案例中看到了另一件事。然后采取下一步，看看你是否不能让gcc看到这种情况。每个优化都在那里，因为一些个人或团体认可了优化并故意将其放在那里。每次有人必须把它放在那里（然后测试它，然后将其保存到将来），这种优化就可以在那里工作。
绝对不要假设代码越少越快，代码越慢越慢，创建和查找不正确的示例非常容易。通常情况下，更少的代码比更多的代码更快。正如我从一开始就证明的那样，你可以创建更多的代码来保存分支，或者循环等，并且最终结果是更快的代码。
底线是您为编译器提供了不同的源，并期望得到相同的结果。问题不在于编译器输出，而在于用户的期望。对于特定的编译器和处理器来说，相当容易演示，添加一行代码会使整个函数显着变慢。例如，为什么改变a = b + 2;到a = b + c + 2;原因_fill_in_the_blank_compiler_name_生成完全不同且速度较慢的代码？答案当然是编译器在输入上输入了不同的代码，因此编译器生成不同的输出是完全有效的。 （更好的是当您交换两条不相关的代码行并导致输出发生显着变化时）输入的复杂性和大小与输出的复杂性和大小之间没有预期的关系。把这样的东西喂给clang：
for(ra=0;ra<20;ra++) dummy(ra);
它产生了60-100行汇编程序。它展开了循环。我没有计算行，如果你考虑它，它必须添加，将结果复制到函数调用的输入，进行函数调用，最少三个操作。所以取决于至少60个指令的目标，如果每个循环四个，则为80，如果每个循环为5，则为100，等等。
答案 2 :(得分：22)
Mysticial已经给出了一个很好的解释，但是我想我会补充说，为什么编译器会为一个编译器而不是另一个编译器进行优化时，没有什么根本的。
例如，LLVM的clang编译器为两个函数提供相同的代码（函数名除外），给出：
_fast_trunc_two: ## @fast_trunc_one
movl %edi, %edx
andl $-2147483648, %edx ## imm = 0xFFFFFFFF80000000
movl %edi, %esi
andl $8388607, %esi ## imm = 0x7FFFFF
orl $8388608, %esi ## imm = 0x800000
shrl $23, %edi
movzbl %dil, %eax
movl $150, %ecx
subl %eax, %ecx
js LBB0_1
shrl %cl, %esi
jmp LBB0_3
LBB0_1: ## %if.then
negl %ecx
shll %cl, %esi
LBB0_3: ## %if.end
movl %edx, %eax
negl %eax
xorl %esi, %eax
addl %edx, %eax
ret
此代码不像OP中的第一个gcc版本那么短，但不像第二个那么长。
来自另一个编译器（我不会命名）的代码，为x86_64编译，为两个函数生成：
fast_trunc_one:
movl %edi, %ecx
shrl $23, %ecx
movl %edi, %eax
movzbl %cl, %edx
andl $8388607, %eax
negl %edx
orl $8388608, %eax
addl $150, %edx
movl %eax, %esi
movl %edx, %ecx
andl $-2147483648, %edi
negl %ecx
movl %edi, %r8d
shll %cl, %esi
negl %r8d
movl %edx, %ecx
shrl %cl, %eax
testl %edx, %edx
cmovl %esi, %eax
xorl %r8d, %eax
addl %edi, %eax
ret
这很有意思，因为它计算if的两边，然后在末尾使用条件移动来选择正确的移动。
Open64编译器产生以下内容：
fast_trunc_one:
movl %edi,%r9d
sarl $23,%r9d
movzbl %r9b,%r9d
addl $-150,%r9d
movl %edi,%eax
movl %r9d,%r8d
andl $8388607,%eax
negl %r8d
orl $8388608,%eax
testl %r8d,%r8d
jl .LBB2_fast_trunc_one
movl %r8d,%ecx
movl %eax,%edx
sarl %cl,%edx
.Lt_0_1538:
andl $-2147483648,%edi
movl %edi,%eax
negl %eax
xorl %edx,%eax
addl %edi,%eax
ret
.p2align 5,,31
.LBB2_fast_trunc_one:
movl %r9d,%ecx
movl %eax,%edx
shll %cl,%edx
jmp .Lt_0_1538
和fast_trunc_two的类似但不完全相同的代码。
无论如何，当涉及到优化时，它就是一个乐透 - 它就是它......它并不总是很容易知道为什么你的代码会以任何特定的方式编译。