我尝试与SSE合作，我遇到了一些奇怪的行为。
我编写简单的代码来比较两个字符串与SSE内在函数，运行它并且它工作。但后来我明白了，在我的代码中，一个指针仍未对齐，但我使用_mm_load_si128指令，这需要指针在16字节边界上对齐。
//Compare two different, not overlapping piece of memory
__attribute((target("avx"))) int is_equal(const void* src_1, const void* src_2, size_t size)
{
//Skip tail for right alignment of pointer [head_1]
const char* head_1 = (const char*)src_1;
const char* head_2 = (const char*)src_2;
size_t tail_n = 0;
while (((uintptr_t)head_1 % 16) != 0 && tail_n < size)
{
if (*head_1 != *head_2)
return 0;
head_1++, head_2++, tail_n++;
}
//Vectorized part: check equality of memory with SSE4.1 instructions
//src1 - aligned, src2 - NOT aligned
const __m128i* src1 = (const __m128i*)head_1;
const __m128i* src2 = (const __m128i*)head_2;
const size_t n = (size - tail_n) / 32;
for (size_t i = 0; i < n; ++i, src1 += 2, src2 += 2)
{
printf("src1 align: %d, src2 align: %d\n", align(src1) % 16, align(src2) % 16);
__m128i mm11 = _mm_load_si128(src1);
__m128i mm12 = _mm_load_si128(src1 + 1);
__m128i mm21 = _mm_load_si128(src2);
__m128i mm22 = _mm_load_si128(src2 + 1);
__m128i mm1 = _mm_xor_si128(mm11, mm21);
__m128i mm2 = _mm_xor_si128(mm12, mm22);
__m128i mm = _mm_or_si128(mm1, mm2);
if (!_mm_testz_si128(mm, mm))
return 0;
}
//Check tail with scalar instructions
const size_t rem = (size - tail_n) % 32;
const char* tail_1 = (const char*)src1;
const char* tail_2 = (const char*)src2;
for (size_t i = 0; i < rem; i++, tail_1++, tail_2++)
{
if (*tail_1 != *tail_2)
return 0;
}
return 1;
}
我打印两个指针的对齐，其中一个指针对齐，但第二个指针 - 不是。并且程序仍然正常且快速地运行。
然后我创建这样的综合测试：
//printChars128(...) function just print 16 byte values from __m128i
const __m128i* A = (const __m128i*)buf;
const __m128i* B = (const __m128i*)(buf + rand() % 15 + 1);
for (int i = 0; i < 5; i++, A++, B++)
{
__m128i A1 = _mm_load_si128(A);
__m128i B1 = _mm_load_si128(B);
printChars128(A1);
printChars128(B1);
}
当我尝试加载指针B时，它在第一次迭代时就像我们预期的那样崩溃了。
有趣的事实是，如果我将target切换为sse4.2，那么is_equal的实施将会崩溃。
另一个有趣的事实是，如果我尝试对齐第二个指针而不是第一个（因此第一个指针将不对齐，第二个对齐），那么is_equal将崩溃。
所以，我的问题是：“如果我启用is_equal指令生成，为什么avx函数只有第一个指针对齐才能正常工作？”
UPD：这是C++代码。我在Windows，x86下使用MinGW64/g++, gcc version 4.9.2编译我的代码。
编译字符串：g++.exe main.cpp -Wall -Wextra -std=c++11 -O2 -Wcast-align -Wcast-qual -o main.exe
答案 0 :(得分：5)
TL：DR ：来自_mm_load_*内在函数的加载可以（在编译时）折叠到其他指令的内存操作数中。 The AVX versions of vector instructions don't require alignment for memory operands，除了vmovdqa等具体对齐的加载/存储指令。
在向量指令的传统SSE编码中（如pxor xmm0, [src1]），未对齐的128位内存操作数将出现故障，除非使用特殊的未对齐加载/存储指令（如movdqu / movups）
VEX-encoding向量指令（如vpxor xmm1, xmm0, [src1]）对未对齐的内存没有错误，除了需要对齐的加载/存储指令（如vmovdqa或{ {3}}）。
_mm_loadu_si128与_mm_load_si128（和store / storeu）内在函数向编译器传达对齐保证，但不强制它实际发出独立的加载指令。 （或者任何东西，如果它已经在寄存器中有数据，就像解除引用标量指针一样）。
在优化使用内在函数的代码时，as-if规则仍然适用。只要不引入故障风险，负载就可以折叠进入使用它的vector-ALU指令的内存操作数。这对于代码密度的原因是有利的，并且由于微融合vmovntdq，在部分CPU中跟踪的微量也更少。执行此操作的优化过程未在-O0启用，因此未经优化的代码构建可能会因未对齐的src1而出现故障。
（相反，这意味着_mm_loadu_*只能用AVX折叠到内存操作数中，而不能用SSE折叠。所以即使在movdqu与指针movqda一样快的CPU上也是如此确实恰好是对齐的，_mm_loadu可能会影响性能，因为movqdu xmm1, [rsi] / pxor xmm0, xmm1是2个融合域uops，前端发布而pxor xmm0, [rsi]只有1。不需要暂存寄存器。另请参阅(see Agner Fog's microarch.pdf)）。
在这种情况下对as-if规则的解释是，在asm的naive转换出现故障的某些情况下，程序不会出错。 （或者相同的代码在未优化的构建中出现故障，但在优化的构建中没有故障）。
这与浮点异常的规则相反，其中编译器生成的代码仍然必须引发在C抽象机上发生的任何和所有异常。这是因为有明确定义的处理FP异常的机制，但不适用于处理段错误。
请注意，由于商店无法折叠到ALU指令的内存操作数中，store（不是storeu）内在函数将编译为代码Micro fusion and addressing modes
// aligned version:
y = ...; // assume it's in xmm1
x = _mm_load_si128(Aptr); // Aligned pointer
res = _mm_or_si128(y, x);
// unaligned version: the same thing with _mm_loadu_si128(Uptr)
当定位SSE（可以在没有AVX支持的CPU上运行的代码）时，对齐版本可以将负载折叠到por xmm1, [Aptr]，但未对齐版本必须使用
movdqu xmm0, [Uptr] / por xmm0, xmm1。如果在OR之后仍然需要y的旧值，则对齐版本也可以这样做。
在定位AVX（gcc -mavx或gcc -march=sandybridge或更高版本）时，发出的所有向量指令（包括128位）都将使用VEX编码。所以你从相同的_mm_...内在函数中获得不同的asm。两个版本都可以编译为vpor xmm0, xmm1, [ptr]。 （并且3操作数非破坏性功能意味着除非加载了原始值多次，否则实际发生这种情况。）
ALU指令只有一个操作数可以是内存操作数，因此在您的情况下必须单独加载。当第一个指针没有对齐时，你的代码会出错，但是并不关心第二个指针的对齐，所以我们可以得出结论，gcc选择用vmovdqa加载第一个操作数并折叠第二个，而不是相反。
您可以在faults with unaligned pointers even when compiling for an AVX target.的代码中看到这种情况。不幸的是，gcc 4.9（和5.3）将它编译成某种次优的代码，在al中生成返回值然后对其进行测试，而不仅仅是对来自vptest的标志进行分支:( clang-3.8确实如此）一个明显更好的工作。
.L36:
add rdi, 32
add rsi, 32
cmp rdi, rcx
je .L9
.L10:
vmovdqa xmm0, XMMWORD PTR [rdi] # first arg: loads that will fault on unaligned
xor eax, eax
vpxor xmm1, xmm0, XMMWORD PTR [rsi] # second arg: loads that don't care about alignment
vmovdqa xmm0, XMMWORD PTR [rdi+16] # first arg
vpxor xmm0, xmm0, XMMWORD PTR [rsi+16] # second arg
vpor xmm0, xmm1, xmm0
vptest xmm0, xmm0
sete al # generate a boolean in a reg
test eax, eax
jne .L36 # then test&branch on it. /facepalm
请注意，您的is_equal为memcmp。我认为glibc的memcmp在许多情况下会比你的实现更好，因为它有the Godbolt compiler explorer和其他处理各种缓冲区相对于彼此错位的情况。 （例如，一个对齐，一个不对齐。）请注意，glibc代码是LGPLed，因此您可能无法复制它。如果您的用例具有通常对齐的较小缓冲区，则您的实现可能很好。在从其他AVX代码调用之前不需要VZEROUPPER也很不错。
最后清理的编译器生成的字节循环肯定是次优的。如果大小大于16个字节，请执行未对齐的加载，该加载以每个src的最后一个字节结束。您重新比较一些已经检查过的字节并不重要。
无论如何，绝对要使用系统memcmp对您的代码进行基准测试。除了库实现之外，gcc知道memcmp的作用，并且有自己的内置定义，可以内联代码。