这是一些相当简单的代码,使用 -O2 (gcc 4.8.5) 编译:
unsigned char * linebuf;
int yuyv_tojpegycbcr(unsigned char * buf, int w)
{
int col;
unsigned char * restrict pix = buf;
unsigned char * restrict line = linebuf;
for(col = 0; col < w - 1; col +=2)
{
line[col*3] = pix[0];
line[col*3 + 1] = pix[1];
line[col*3 + 2] = pix[3];
line[col*3 + 3] = pix[2];
line[col*3 + 4] = pix[1];
line[col*3 + 5] = pix[3];
pix += 4;
}
return 0;
}
这是相应的组件:
0000000000000000 <yuyv_tojpegycbcr>:
0: 83 fe 01 cmp $0x1,%esi
3: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # a <yuyv_tojpegycbcr+0xa>
a: 7e 4e jle 5a <yuyv_tojpegycbcr+0x5a>
c: 83 ee 02 sub $0x2,%esi
f: 31 d2 xor %edx,%edx
11: d1 ee shr %esi
13: 48 8d 74 76 03 lea 0x3(%rsi,%rsi,2),%rsi
18: 48 01 f6 add %rsi,%rsi
1b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
20: 0f b6 0f movzbl (%rdi),%ecx
23: 48 83 c2 06 add $0x6,%rdx
27: 48 83 c7 04 add $0x4,%rdi
2b: 48 83 c0 06 add $0x6,%rax
2f: 88 48 fa mov %cl,-0x6(%rax)
32: 0f b6 4f fd movzbl -0x3(%rdi),%ecx
36: 88 48 fb mov %cl,-0x5(%rax)
39: 0f b6 4f ff movzbl -0x1(%rdi),%ecx
3d: 88 48 fc mov %cl,-0x4(%rax)
40: 0f b6 4f fe movzbl -0x2(%rdi),%ecx
44: 88 48 fd mov %cl,-0x3(%rax)
47: 0f b6 4f fd movzbl -0x3(%rdi),%ecx
4b: 88 48 fe mov %cl,-0x2(%rax)
4e: 0f b6 4f ff movzbl -0x1(%rdi),%ecx
52: 88 48 ff mov %cl,-0x1(%rax)
55: 48 39 f2 cmp %rsi,%rdx
58: 75 c6 jne 20 <yuyv_tojpegycbcr+0x20>
5a: 31 c0 xor %eax,%eax
5c: c3 retq
在没有限制限定符的情况下编译时,输出是相同的: 大量混合负载和存储。有些值加载了两次,看起来没有发生优化。如果
pix
和 line
没有别名,我希望编译器足够智能,并且仅加载 pix[1] 和 pix[3] 一次。
您知道有什么可能会取消
restrict
限定符的资格吗?
PS: 使用较新的 gcc (4.9.2),在另一个架构 (arm v7) 上,结果是相似的。这是一个测试脚本,用于比较有限制和没有限制的生成代码。
#!/bin/sh
gcc -c -o test.o -std=c99 -O2 yuyv_to_jpegycbcr.c
objdump -d test.o > test.S
gcc -c -o test2.o -O2 -D restrict='' yuyv_to_jpegycbcr.c
objdump -d test2.o > test2.S
将限制放在函数参数而不是局部变量上。
根据我的经验,大多数编译器(包括 GCC)仅在函数参数上指定时才使用限制。函数内对局部变量的所有使用都将被忽略。
我怀疑这与在函数级别而不是基本块级别进行的别名分析有关。但我没有证据支持这一点。此外,它可能因编译器和编译器版本而异。
无论如何,这些东西的依赖都非常挑剔。因此,如果性能很重要,要么手动优化它,要么记得每次升级或更改编译器时重新访问它。