我最近遇到了一个奇怪的去优化（或者更确切地说错过了优化机会）。
考虑使用此函数将3位整数数组有效解包为8位整数。它在每次循环迭代中解包16个int：
void unpack3bit(uint8_t* target, char* source, int size) {
while(size > 0){
uint64_t t = *reinterpret_cast<uint64_t*>(source);
target[0] = t & 0x7;
target[1] = (t >> 3) & 0x7;
target[2] = (t >> 6) & 0x7;
target[3] = (t >> 9) & 0x7;
target[4] = (t >> 12) & 0x7;
target[5] = (t >> 15) & 0x7;
target[6] = (t >> 18) & 0x7;
target[7] = (t >> 21) & 0x7;
target[8] = (t >> 24) & 0x7;
target[9] = (t >> 27) & 0x7;
target[10] = (t >> 30) & 0x7;
target[11] = (t >> 33) & 0x7;
target[12] = (t >> 36) & 0x7;
target[13] = (t >> 39) & 0x7;
target[14] = (t >> 42) & 0x7;
target[15] = (t >> 45) & 0x7;
source+=6;
size-=6;
target+=16;
}
}
这是为部分代码生成的程序集：
...
367: 48 89 c1 mov rcx,rax
36a: 48 c1 e9 09 shr rcx,0x9
36e: 83 e1 07 and ecx,0x7
371: 48 89 4f 18 mov QWORD PTR [rdi+0x18],rcx
375: 48 89 c1 mov rcx,rax
378: 48 c1 e9 0c shr rcx,0xc
37c: 83 e1 07 and ecx,0x7
37f: 48 89 4f 20 mov QWORD PTR [rdi+0x20],rcx
383: 48 89 c1 mov rcx,rax
386: 48 c1 e9 0f shr rcx,0xf
38a: 83 e1 07 and ecx,0x7
38d: 48 89 4f 28 mov QWORD PTR [rdi+0x28],rcx
391: 48 89 c1 mov rcx,rax
394: 48 c1 e9 12 shr rcx,0x12
398: 83 e1 07 and ecx,0x7
39b: 48 89 4f 30 mov QWORD PTR [rdi+0x30],rcx
...
它看起来很有效。简单地将右移，然后是和，然后将存储到目标缓冲区。但是现在，看看当我将函数更改为结构中的方法时会发生什么：
struct T{
uint8_t* target;
char* source;
void unpack3bit( int size);
};
void T::unpack3bit(int size) {
while(size > 0){
uint64_t t = *reinterpret_cast<uint64_t*>(source);
target[0] = t & 0x7;
target[1] = (t >> 3) & 0x7;
target[2] = (t >> 6) & 0x7;
target[3] = (t >> 9) & 0x7;
target[4] = (t >> 12) & 0x7;
target[5] = (t >> 15) & 0x7;
target[6] = (t >> 18) & 0x7;
target[7] = (t >> 21) & 0x7;
target[8] = (t >> 24) & 0x7;
target[9] = (t >> 27) & 0x7;
target[10] = (t >> 30) & 0x7;
target[11] = (t >> 33) & 0x7;
target[12] = (t >> 36) & 0x7;
target[13] = (t >> 39) & 0x7;
target[14] = (t >> 42) & 0x7;
target[15] = (t >> 45) & 0x7;
source+=6;
size-=6;
target+=16;
}
}
我认为生成的程序集应该完全相同，但事实并非如此。这是它的一部分：
...
2b3: 48 c1 e9 15 shr rcx,0x15
2b7: 83 e1 07 and ecx,0x7
2ba: 88 4a 07 mov BYTE PTR [rdx+0x7],cl
2bd: 48 89 c1 mov rcx,rax
2c0: 48 8b 17 mov rdx,QWORD PTR [rdi] // Load, BAD!
2c3: 48 c1 e9 18 shr rcx,0x18
2c7: 83 e1 07 and ecx,0x7
2ca: 88 4a 08 mov BYTE PTR [rdx+0x8],cl
2cd: 48 89 c1 mov rcx,rax
2d0: 48 8b 17 mov rdx,QWORD PTR [rdi] // Load, BAD!
2d3: 48 c1 e9 1b shr rcx,0x1b
2d7: 83 e1 07 and ecx,0x7
2da: 88 4a 09 mov BYTE PTR [rdx+0x9],cl
2dd: 48 89 c1 mov rcx,rax
2e0: 48 8b 17 mov rdx,QWORD PTR [rdi] // Load, BAD!
2e3: 48 c1 e9 1e shr rcx,0x1e
2e7: 83 e1 07 and ecx,0x7
2ea: 88 4a 0a mov BYTE PTR [rdx+0xa],cl
2ed: 48 89 c1 mov rcx,rax
2f0: 48 8b 17 mov rdx,QWORD PTR [rdi] // Load, BAD!
...
如您所见，我们在每次移位之前从内存中引入了额外的冗余load（mov rdx， QWORD PTR[rdi]）。似乎目标指针（现在是成员而不是局部变量）必须在存储到其中之前始终重新加载。这大大降低了代码速度（在我的测量中约为15%）。
首先，我想也许C内存模型强制成员指针可能不存储在寄存器中，但必须重新加载，但这似乎是一个尴尬的选择，因为它会使许多可行的优化变得不可能。所以我非常惊讶编译器没有在这里将target存储在寄存器中。
我尝试将成员指针自己缓存到局部变量中：
void T::unpack3bit(int size) {
while(size > 0){
uint64_t t = *reinterpret_cast<uint64_t*>(source);
uint8_t* target = this->target; // << ptr cached in local variable
target[0] = t & 0x7;
target[1] = (t >> 3) & 0x7;
target[2] = (t >> 6) & 0x7;
target[3] = (t >> 9) & 0x7;
target[4] = (t >> 12) & 0x7;
target[5] = (t >> 15) & 0x7;
target[6] = (t >> 18) & 0x7;
target[7] = (t >> 21) & 0x7;
target[8] = (t >> 24) & 0x7;
target[9] = (t >> 27) & 0x7;
target[10] = (t >> 30) & 0x7;
target[11] = (t >> 33) & 0x7;
target[12] = (t >> 36) & 0x7;
target[13] = (t >> 39) & 0x7;
target[14] = (t >> 42) & 0x7;
target[15] = (t >> 45) & 0x7;
source+=6;
size-=6;
this->target+=16;
}
}
这段代码也产生了没有额外存储的“好”汇编器。所以我的猜测是：编译器不允许吊起结构的成员指针的负载，所以这样的“热指针”应该总是存储在局部变量中。
使用的编译器是g 4.8.2-19ubuntu1，带有-O3优化。我还尝试了clang 3.4-1ubuntu3，结果相似：Clang甚至能够使用本地目标指针向量化方法。然而，使用this-
我检查了一些类似方法的汇编器，结果是一样的：似乎this的成员总是必须在存储之前重新加载，即使这样的加载可以简单地在循环之外提升。我将不得不重写很多代码来摆脱这些额外的存储，主要是通过将指针自己缓存到热代码上方声明的局部变量中。但我一直认为摆弄诸如在局部变量中缓存指针之类的细节肯定有资格在编译器变得如此聪明的这些日子里过早优化。但似乎我在这里错了。在热循环中缓存成员指针似乎是一种必要的手动优化技术。
指针混淆现象似乎是问题所在，讽刺的是this和this-
这个-
在这种情况下，写入this-
内存混淆现象问题不限于上述，原则上任何使用this-
我更精通C语言，可以通过使用__restrict__关键字声明指针变量来解决这个问题。
严格的混淆现象规则允许char*别名为任何其他指针。所以this-
target[0] = t & 0x7;
target[1] = (t >> 3) & 0x7;
target[2] = (t >> 6) & 0x7;
事实上是
this->target[0] = t & 0x7;
this->target[1] = (t >> 3) & 0x7;
this->target[2] = (t >> 6) & 0x7;
由于this可能会在您修改this时被修改-
一旦this-
这里的问题是严格的混淆现象，它说我们被允许通过char*进行别名，因此在您的情况下会阻止编译器优化。我们不允许通过不同类型的指针进行别名，这将是未定义的行为，通常在SO我们看到这个问题是用户试图通过不兼容的指针类型进行别名。
将uint8_t实现为无符号字符似乎是合理的，如果我们查看Coliru上的cstdint，它包括stdint. h，其typedefuint8_t如下：
typedef unsigned char uint8_t;
如果您使用了另一种非char类型，那么编译器应该能够优化。
这在C标准草案部分3.10左值和右值中进行了介绍，其中规定：
如果程序试图通过以下类型之一以外的glvalue访问对象的存储值，则行为未定义
并包括以下项目符号：
注意，我在一个问题中发布了一个关于可能的工作的评论，该问题问什么时候uint8_t≠无符号字符？建议是：
然而，最简单的解决方法是使用限制关键字，或者将指针复制到一个本地变量，该变量的地址永远不会被采用，这样编译器就不需要担心uint8_t对象是否可以将其别名。
由于C不支持限制关键字，您必须依赖编译器扩展，例如gcc使用__restrict__因此这不是完全可移植的，但另一个建议应该是。
