【发布时间】：2015-06-04 10:29:50
【问题描述】：
如果乘法的操作数之一恰好是 1.0，x86(64 too) 处理器是否会优化掉乘法？
PS：我的意思不是编译器优化 1.0 的常数乘法。
【问题讨论】：
-
那里有很多 x86 处理器。一般来说，乘法时间可能取决于某些 CPU 上的操作数。
标签： optimization x86 processor
【发布时间】：2015-06-04 10:29:50
【问题描述】：
这不是我在文档中看到的有关指令延迟或 Intel 或 AMD CPU 微架构的内容。
我怀疑这不会发生，因为可变延迟会干扰流水线执行单元。 （在同一个时钟周期内来自同一个执行单元的多个结果 = 额外的复杂性）。此外，可能还有其他一些逻辑位（uop 调度/排队、结果转发网络）是围绕每个具有已知延迟的 uop 设计的。 （除除/sqrt 等特殊情况除外）。
IIRC，一位分析师，可能是 Agner Fog 或 David Kanter，建议某些微指令可能以 2 个周期延迟实现，但需要 3 个周期来匹配其执行端口可以处理的其他微指令。因此，对于 Intel CPU 设计而言，持续的操作延迟似乎是一个大问题，以至于值得让操作变慢。
请注意，我们在这里只讨论延迟。如果您的乘法不是循环携带的依赖链的一部分，或者您有足够多的独立乘法，您可以让乘法器在每个时钟执行一次操作。
Haswell CPU 可以维持每个时钟 2 个 FP 矢量乘法的吞吐量。 （256b 个向量，4 个双精度数或 8 个浮点数）。延迟 = 5 个时钟周期，结果准备就绪，与输入无关。或每个时钟 1 个向量整数乘法。 （向量乘法 ALU 在端口 0。向量 FP 乘法器在端口 0 和端口 1）。
尽可能避免相乘，这会导致长依赖链。 （这通常用于整数乘法来计算循环索引。当您编写循环以将计数器增加 16 时，编译器会做得更好，而不是将 i++ 乘以 16 作为数组索引。）
【讨论】：