为什么即使使用-FFAST -MATH，为什么不使用浮子来优化2^n的乘法，从而将乘法优化2^n？

Question

考虑到此功能，

float mulHalf(float x) {
    return x * 0.5f;
}

以下功能会使用 normal 输入/输出产生相同的结果。

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-MAT​​H的汇编输出。

mulHalf:
        mulss   xmm0, DWORD PTR .LC0[rip]
        ret

mulHalf_opt:
        paddd   xmm0, XMMWORD PTR .LC1[rip]
        ret

-FFAST-MAT​​H启用-ffinite-Math-Math-golly“假定参数和结果不是NANS或 +-Infs”

因此，mulhalf的编译输出可以更好地使用paddd与-ffast-math上的paddd，如果这样做会在的公差下产生更快的代码。 -FFAST-MAT​​H。

我从。

(MULSS)
Architecture    Latency Throughput (CPI)
Skylake         4       0.5
Broadwell       3       0.5
Haswell         5       0.5
Ivy Bridge      5       1

(PADDD)
Architecture    Latency Throughput (CPI)
Skylake         1       0.33
Broadwell       1       0.5
Haswell         1       0.5
Ivy Bridge      1       0.5

显然，PADD是一个更快的指令。然后我想也许是因为整数和浮点单元之间的旁路延迟。

此答案显示了Agner Fog的表格。

Processor                       Bypass delay, clock cycles 
  Intel Core 2 and earlier        1 
  Intel Nehalem                   2 
  Intel Sandy Bridge and later    0-1 
  Intel Atom                      0 
  AMD                             2 
  VIA Nano                        2-3 

看到这一点，paddd似乎仍然是赢家，尤其是在CPU上，尤其是Sandy Bridge的CPU，但对于最近的CPU指定-March，只需更改MULS vmulss，具有相似的延迟/吞吐量。

为什么GCC和Clang不用float to paddd将乘法优化2^n，即使使用-ffast-Math？

Answer 1

这将使0.0F 的输入失败，-ffast-Math-Math不排除。 （尽管从技术上讲，这是一个恰好的亚正态分子的特殊情况，也恰好是Mantissa。）。

整数扣除将包裹到全部指数字段，然后翻转符号位，因此您将获得0.0F * 0.5F * 0.5F生产-Inf，这根本不是可以接受。

@chtz指出，可以使用psubusw来修复+0.0F情况，但对于-0.0.0f - ＆gt; +INF。因此，不幸的是，即使使用-FFAST-MAT​​H允许零的“错误”符号，这也是不可用的。但是，即使快速记忆，无限态度和NAN的完全错误也是不可取的。

---

除此之外，是的，我认为这将有效，并在旁路延迟与Nehalem以外的CPU中付费，即使在其他FP指令之间使用了。

0.0行为是一种展示器。除此之外，与其他输入相比，在FP乘以的情况下，底流程的理想程度要少得多，例如，即使设置了FTZ（输出时冲洗至零），也会产生亚正常。用DAZ集（Denmals为零）读取它的代码仍然可以正确处理它，但是对于具有最小归一化指数（编码为1）的数字，FP Bit-Pattern也可能是错误的非零mantissa。例如，由于将归一化数字乘以0.5F，您可以获得0x00000001的0x00000001。

即使不是为了0.0F Showstopper，这种怪异可能比海湾合作委员会愿意对人造成的怪异。因此，即使对于GCC可以证明非零的情况，我也不会期望它，除非它也可以远离flt_min。这可能很少是不值得寻找的。

，当您知道它是安全的时候，您当然可以手动执行此操作，尽管Simd Interinss更加方便。我希望Scalar Type-typunn中的ASM相当糟糕，大概是2x movd 围绕整数sub，而不是将其保留在paddd时，仅当您只想要低标量fp元素时。

Godbolt for几次尝试 ，包括直接的内在物质，这些内在物质仅像我们希望的那样call缩编译到内存源paddd。 Clang的Shuffle Optimizer认为上部元素是“死”（_MM_CVTSS_F32仅读取底部的元素），并且能够将它们视为“不在乎”。

// clang compiles this fully efficiently
// others waste an instruction or more on _mm_set_ss to zero the upper XMM elements
float mulHalf_opt_intrinsics(float x) {
    __m128i e = _mm_set1_epi32(-1u << 23);
    __m128 vx = _mm_set_ss(x);
    vx = _mm_castsi128_ps( _mm_add_epi32(_mm_castps_si128(vx), e) );
    return _mm_cvtss_f32(vx);
}

和普通标量版。我尚未测试它是否可以自动矢量化，但可以想象它可以做到这一点。否则，GCC和Clang均进行MOVD/add/movd（或sub）将值反弹至GP-Integer寄存器。

float mulHalf_opt_memcpy_scalar(float x) {
    uint32_t xi;
    memcpy(&xi, &x, sizeof(x));
    xi += -1u << 23;
    memcpy(&x, &xi, sizeof(x));
    return x;
}