例如，使用 IEEE-754 32 位二进制浮点数，让我们表示 的值1 / 3。它无法精确完成，但0x3eaaaaab会产生最接近 的值1 / 3。您可能希望以十进制形式写入值，并让编译器将十进制文字转换为二进制浮点数。
0.333333f -> 0x3eaaaa9f (0.333332986)\n0.3333333f -> 0x3eaaaaaa (0.333333313)\n0.33333333f -> 0x3eaaaaab (0.333333343)\n0.333333333f -> 0x3eaaaaab (0.333333343)\n您可以看到 8 位（有效）十进制数字足以表示尽可能正确的值（最接近实际值）。
\n我用 \xcf\x80 和 e（自然对数的底数）进行了测试，两者都需要 8 位十进制数字才能最正确。
\n3.14159f -> 0x40490fd0 (3.14159012)\n3.141593f -> 0x40490fdc (3.14159298)\n3.1415927f -> 0x40490fdb (3.14159274)\n3.14159265f -> 0x40490fdb (3.14159274)\n\n2.71828f -> 0x402df84d (2.71828008)\n2.718282f -> 0x402df855 (2.71828198)\n2.7182818f -> 0x402df854 (2.71828175)\n2.71828183f -> 0x402df854 (2.71828175)\n不过，\xe2\x88\x9a2似乎需要 9 位数字。
1.41421f -> 0x3fb504d5 (1.41420996)\n1.414214f -> 0x3fb504f7 …据我所知，SSE/AVX 中没有用于加载立即数的指令。一种解决方法是将值加载到普通寄存器 和movd，但编译器似乎认为这比从内存加载成本更高，即使对于单个标量值也是如此。
这使得每次使用常见常量（例如1、0x80000000、0x7fffffff、0x3f800000、0x3f000000等）进行操作时都需要进行内存访问。好吧，将这些值编码在机器代码中每个将占用 4 个字节，但 32 位绝对或rip相对地址也是如此，而且我相信立即加载比任何类型的内存加载都便宜。
我一直认为有类似movss xmm, imm32或 之类的东西broadcastss xmm, imm32会很好，但不做出这样的指示肯定是有原因的。为什么要这样设计呢？
我正在制作一个供个人使用的小型游戏引擎。目标架构是 x86_64，最好使用 SSE2。
\n正弦/余弦函数是核心部分之一，它是作为输入范围的 1024 个余弦值的预先计算表来实现的[0, \xcf\x80 / 2]。
标量的实现非常简单。
\ntypedef unsigned uns;\ntypedef float flt;\n\nenum {COS_TABLE_SIZE = 1 << 10};\nextern flt COS_TABLE[COS_TABLE_SIZE];\n\nflt f(uns i) {\n flt *t = COS_TABLE;\n uns z = COS_TABLE_SIZE;\n switch (i / z) {\n case 0:\n return +t[+(i - z * 0) + 0];\n case 1:\n return -t[-(i - z * 1) + z];\n case 2:\n return -t[+(i - z * 2) + 0];\n case 3:\n return +t[-(i - z * …我正在尝试在不使用内联汇编的情况下有效地实现SHLD和SHRD说明x86。
uint32_t shld_UB_on_0(uint32_t a, uint32_t b, uint32_t c) {
return a << c | b >> 32 - c;
}
似乎有效，但当c == 0第二个移位的操作数变为时会调用未定义的行为32。SHLD第三个操作数的实际指令0被明确定义为不执行任何操作。（https://www.felixcloutier.com/x86/shld）
uint32_t shld_broken_on_0(uint32_t a, uint32_t b, uint32_t c) {
return a << c | b >> (-c & 31);
}
不会调用未定义的行为，但当c == 0结果是a | b而不是a.
uint32_t shld_safe(uint32_t a, uint32_t b, uint32_t c) {
if (c == …Currently, from research and various attempts, I'm pretty sure that the only solution to this problem is to use assembly. I'm posting this question to show an existing problem, and maybe get attention from compiler developers, or get some hits from searches about similar problems.
If anything changes in the future, I will accept it as an answer.
This is a very related question for MSVC.
In x86_64 machines, it is faster to use div/idiv with a 32-bit …
考虑到这个功能，
float mulHalf(float x) {
return x * 0.5f;
}
以下函数与正常输入/输出产生相同的结果。
float mulHalf_opt(float x) {
__m128i e = _mm_set1_epi32(-1 << 23);
__asm__ ("paddd\t%0, %1" : "+x"(x) : "xm"(e));
return x;
}
这是带有 的汇编输出-O3 -ffast-math。
mulHalf:
mulss xmm0, DWORD PTR .LC0[rip]
ret
mulHalf_opt:
paddd xmm0, XMMWORD PTR .LC1[rip]
ret
-ffast-math启用-ffinite-math-only“假设参数和结果不是 NaN 或 +-Infs” [1]。
因此，如果在 的容差下生成更快的代码，则的编译输出可能会更好地与onmulHalf一起使用。paddd-ffast-math-ffast-math
我从Intel Intrinsics Guide中获得了下表。
(MULSS)
Architecture Latency Throughput (CPI)
Skylake 4 0.5 …这是提高精度的像素混合操作的一部分。
typedef unsigned uint;
uint h(uint x) {
x &= 0xff;
return x << 8 | x;
}
uint g(uint x, uint y) {
return h(x) * h(y) >> 24;
}
我查看了编译器的输出，发现了一行非常有趣的内容。
g:
movzx edi, dil
movzx esi, sil
imul esi, edi
imul eax, esi, 66049 # <---
shr eax, 24
ret
这可以反编译为，
uint g_(uint x, uint y) {
return (x & 0xff) * (y & 0xff) * 66049 >> 24;
}
我无法理解乘以66049如何产生所需的结果。它背后的数学原理是什么？