VS：_BitScanReverse64 内在的意外优化行为

Question

以下代码在调试模式下运行良好，因为定义了 _BitScanReverse64 如果未设置位，则为 return 0。 Citing MSDN: （return 值为）"Nonzero if Index was set, or 0 if no set bits were found."

如果我在发布模式下编译这段代码它仍然有效，但如果我启用编译器优化，例如 \O1 或 \O2 索引不为零并且 assert() 失败。

#include <iostream>
#include <cassert>

using namespace std;

int main()
{
  unsigned long index = 0;
  _BitScanReverse64(&index, 0x0ull);

  cout << index << endl;

  assert(index == 0);

  return 0;
}

这是预期的行为吗？我正在使用 Visual Studio Community 2015，版本 14.0.25431.01 Update 3。（我保留了 cout，以便在优化期间不会删除变量索引）。还有一种有效的解决方法，还是我不应该直接使用这个编译器内部函数？

Answer 1

AFAICT，当输入为零时，index 内部函数会在 index 中留下垃圾， 比 asm 指令的行为更弱。这就是为什么它有一个单独的布尔值 return 值和整数输出操作数。

尽管 index arg 被引用，编译器将其视为仅输出。

unsigned char _BitScanReverse64 (unsigned __int32* index, unsigned __int64 mask)
Intel's intrinsics guide documentation for the same intrinsic seems clearer than the Microsoft docs 您已链接，并阐明了 MS 文档试图表达的内容。但仔细阅读，他们似乎都在说同样的话，并描述了 bsr 指令周围的薄包装。

Intel documents the BSR instruction 当输入为 0 时产生 "undefined value"，但在这种情况下设置 ZF。 但 AMD 将其记录为离开目的地不变：

AMD's BSF entry in AMD64 Architecture Programmer’s Manual Volume 3: General-Purpose and System Instructions

... If the second operand contains 0, the instruction sets ZF to 1 and does not change the contents of the destination register. ...

在当前的 Intel 硬件上，实际行为与 AMD 的文档相匹配：当 src 操作数为 0 时，目标寄存器保持不变。也许这就是为什么 MS 将其描述为仅在输入为非时设置 Index -零（并且内在函数的 return 值为非零）。

在 Intel () 上，甚至没有将 64 位寄存器截断为 32 位。例如mov rax,-1; bsf eax, ecx（ECX 归零）留下 RAX=-1（64 位），而不是您从 xor eax, 0 得到的 0x00000000ffffffff。但是对于非零 ECX，bsf eax, ecx 具有零扩展到 RAX 的通常效果，例如 RAX=3.

IDK 为什么 Intel 仍然没有记录它。 也许一个非常老的 x86 CPU（像原来的 386？）以不同的方式实现它？ Intel 和 AMD 经常 go above and beyond what's documented in the x86 manuals in order to not break existing widely-used code (e.g. Windows)，这可能就是这样开始的。

在这一点上，英特尔似乎不太可能放弃该输出依赖性并为输入 =0 保留实际垃圾或 -1 或 32，但由于缺乏文档，该选项处于打开状态。

Skylake 删除了 lzcnt 和 tzcnt 的错误依赖（后来的 uarch 删除了 popcnt 的错误依赖），同时仍然保留了 bsr/ 的依赖bsf。 (Why does breaking the "output dependency" of LZCNT matter?)

当然，由于 MSVC 优化了你的 index = 0 初始化，大概它只是使用它想要的任何目标寄存器，不一定是保存 C 变量先前值的寄存器。 因此，即使您愿意，我也不认为您可以利用 dst-unmodified 行为，即使它在 AMD 上得到保证。

所以在 C++ 术语中，内部函数对 index 没有输入依赖性。但是在 asm 中，指令确实对 dst 寄存器有输入依赖性，就像 add dst, src 指令一样。如果编译器不小心，这可能会导致意外的性能问题。

不幸的是，在 Intel 硬件上，popcnt / lzcnt / tzcnt asm instructions also have a false dependency on their destination，即使结果从不依赖于它。不过，编译器现在已经知道了这个问题，因此您在使用内部函数时不必担心它（除非您的编译器已经使用了几年以上，因为它是最近才发现的）。

您需要检查它以确保 index 有效，除非您知道输入非零。例如

if(_BitScanReverse64(&idx, input)) {
    // idx is valid.
    // (MS docs say "Index was set")
} else {
    // input was zero, idx holds garbage.
    // (MS docs don't say Index was even set)
    idx = -1;     // might make sense, one lower than the result for bsr(1)
}

如果你想避免这个额外的检查分支，如果你的目标是足够新的硬件（例如 Intel Haswell 或 AMD Bulldozer IIRC），你可以通过不同的内在函数使用 lzcnt instruction。它 "works" 即使输入全为零，并且实际上计算前导零而不是 return 设置最高位的索引。

VS：_BitScanReverse64 内在的意外优化行为

VS: unexpected optimization behavior with _BitScanReverse64 intrinsic

c++

optimization

x86-64

intrinsics

visual-studio