我使用VS2012 C编译器测试了代码的“精简”版本。
int main()
{
int A[12] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 };
int sum = 0;
int i;
for (i = 0; i < 12; ++i)
sum += A[11 - i];
printf("%d\n", sum);
return 0;
}
我在 x64 模式下以 Release 配置编译它,并进行了速度优化。尽管如此,这个 bug 仍然存在,但取决于其他的优化和代码生成设置,它会以不同的方式表现出来。其中一个版本的代码产生了“随机”的结果,而另一个版本则始终将8
作为总和(而不是正确的12
)。
对于那个一直产生8
的版本,生成的代码就像这样:
000000013FC81DF0 mov rax,rsp
000000013FC81DF3 sub rsp,68h
000000013FC81DF7 movd xmm1,dword ptr [rax-18h]
000000013FC81DFC movd xmm2,dword ptr [rax-10h]
000000013FC81E01 movd xmm5,dword ptr [rax-0Ch]
000000013FC81E06 xorps xmm0,xmm0
000000013FC81E09 xorps xmm3,xmm3
for (i = 0
000000013FC81E0C xor ecx,ecx
000000013FC81E0E mov dword ptr [rax-48h],1
000000013FC81E15 mov dword ptr [rax-44h],1
000000013FC81E1C mov dword ptr [rax-40h],1
000000013FC81E23 punpckldq xmm2,xmm1
000000013FC81E27 mov dword ptr [rax-3Ch],1
000000013FC81E2E mov dword ptr [rax-38h],1
000000013FC81E35 mov dword ptr [rax-34h],1
{
sum += A[11 - i]
000000013FC81E3C movdqa xmm4,xmmword ptr [__xmm@00000001000000010000000100000001 (013FC83360h)]
000000013FC81E44 paddd xmm4,xmm0
000000013FC81E48 movd xmm0,dword ptr [rax-14h]
000000013FC81E4D mov dword ptr [rax-30h],1
000000013FC81E54 mov dword ptr [rax-2Ch],1
000000013FC81E5B mov dword ptr [rax-28h],1
000000013FC81E62 mov dword ptr [rax-24h],1
000000013FC81E69 punpckldq xmm5,xmm0
000000013FC81E6D punpckldq xmm5,xmm2
000000013FC81E71 paddd xmm5,xmm3
000000013FC81E75 paddd xmm5,xmm4
000000013FC81E79 mov dword ptr [rax-20h],1
000000013FC81E80 mov dword ptr [rax-1Ch],1
000000013FC81E87 mov r8d,ecx
000000013FC81E8A movdqa xmm0,xmm5
000000013FC81E8E psrldq xmm0,8
000000013FC81E93 paddd xmm5,xmm0
000000013FC81E97 movdqa xmm0,xmm5
000000013FC81E9B lea rax,[rax-40h]
000000013FC81E9F mov r9d,2
000000013FC81EA5 psrldq xmm0,4
000000013FC81EAA paddd xmm5,xmm0
000000013FC81EAE movd edx,xmm5
000000013FC81EB2 nop word ptr [rax+rax]
{
sum += A[11 - i]
000000013FC81EC0 add ecx,dword ptr [rax+4]
000000013FC81EC3 add r8d,dword ptr [rax]
000000013FC81EC6 lea rax,[rax-8]
000000013FC81ECA dec r9
000000013FC81ECD jne main+0D0h (013FC81EC0h)
}
printf("%d\n", sum)
000000013FC81ECF lea eax,[r8+rcx]
000000013FC81ED3 lea rcx,[__security_cookie_complement+8h (013FC84040h)]
000000013FC81EDA add edx,eax
000000013FC81EDC call qword ptr [__imp_printf (013FC83140h)]
return 0
000000013FC81EE2 xor eax,eax
}
000000013FC81EE4 add rsp,68h
000000013FC81EE8 ret
代码生成器和优化器留下了许多奇怪且看似不必要的术语,但这段代码的作用可以简单地描述如下。
该程序使用两种独立的算法来产生最终的总和,这两种算法显然应该处理数组的不同部分。我猜测两个处理流程(非 SSE 和 SSE)被用于通过指令流水线提高并行性。
其中一个算法是一个简单的循环,它对数组元素求和,每次迭代处理两个元素。它可以从上述“交错”的代码中提取如下:
000000013F1E1E0C xor ecx,ecx
000000013F1E1E87 mov r8d,ecx
000000013F1E1E9B lea rax,[rax-40h]
000000013F1E1E9F mov r9d,2
000000013F1E1EC0 add ecx,dword ptr [rax+4]
000000013F1E1EC3 add r8d,dword ptr [rax]
000000013F1E1EC6 lea rax,[rax-8]
000000013F1E1ECA dec r9
000000013F1E1ECD jne main+0D0h (013F1E1EC0h)
这个算法从地址 rax - 40h
开始添加元素,在我的实验中它等于 &A[2]
,向后跳过两个元素进行两次迭代。这样可以在寄存器 r8
中累加 A[0]
和 A[2]
的和以及在寄存器 ecx
中累加 A[1]
和 A[3]
的和。因此,该算法的这一部分处理数组的4个元素,并正确生成值 2
在 r8
和 ecx
中。
该算法的另一部分使用SSE指令编写,显然负责将数组的剩余部分相加。可以从代码中提取如下:
000000013F1E1E3C movdqa xmm4,xmmword ptr [__xmm@00000001000000010000000100000001 (013F1E3360h)]
000000013F1E1E75 paddd xmm5,xmm4
000000013F1E1E8A movdqa xmm0,xmm5
000000013F1E1E8E psrldq xmm0,8
000000013F1E1E93 paddd xmm5,xmm0
000000013F1E1E8A movdqa xmm0,xmm5
000000013F1E1E8E psrldq xmm0,4
000000013F1E1E93 paddd xmm5,xmm0
000000013F1E1EAE movd edx,xmm5
该部分使用的通用算法很简单:它将值 0x00000001000000010000000100000001
放入 128 位寄存器 xmm5
,然后向右移动 8 字节(0x00000000000000000000000100000001
),并将其添加到原始值中,生成 0x00000001000000010000000200000002
。这再次向右移动 4 个字节(0x00000000000000010000000100000002
)并再次添加到前一个值中,生成 0x00000001000000020000000300000004
。寄存器 xmm5
的最后 32 位字 0x00000004
被视为结果,并放置在寄存器 edx
中。因此,该算法将 4
作为其最终结果。很明显,该算法仅对 128 位寄存器中连续的 32 位字执行“并行”加法。顺便说一下,该算法甚至不尝试访问 A
,它从编译器/优化器产生的嵌入式常量开始求和。
现在,最终报告 r8 + ecx + edx
的值作为最终总和。显然,这仅为 8
,而不是正确的 12
。看起来其中一个算法忘记做了一些工作。我不知道是哪个,但从“冗余”指令的丰富程度来判断,似乎应该是 SSE 算法应该在 edx
中生成 8
而不是 4
。有一个可疑的指令是这个:
000000013FC81E71 paddd xmm5,xmm3
那时,xmm3
始终包含零。因此,这条指令看起来完全是多余的和不必要的。但是如果 xmm3
实际上包含另一个代表数组中另外4个元素的“魔法”常量(就像 xmm4
一样),那么该算法将正常工作并产生适当的总和。
如果为数组元素使用不同的初始值
int A[12] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 };
可以清楚地看到,第一个(非SSE)算法成功地对1、2、3、4
进行了求和,而第二个(SSE)算法对9、10、11、12
进行了求和。5、6、7、8
未被考虑在内,导致最终的总和是 52
,而不是正确的 78
。
这明显是编译器/优化器的bug。
附言:相同设置的同一项目导入VS2013更新2后似乎没有出现此bug。
+123
真的必要吗?请注意不要改变原意并尽量让译文易于理解。 - MSaltersi <= 10
或更低,就可以消除它了(可能在这种情况下循环被展开了)。 - bcrist