位运算符，而不是在分支中使用异或

问完后这个问题 https://stackoverflow.com/questions/22336015/why-use-xor-with-a-literal-instead-of-inversion-bitwise-not，我收到了 @AndonM.Coleman 的一条非常有趣的评论，我必须验证它。

由于反汇编代码是为 x86 编写的，因此值得指出的是，XOR 将设置/清除零标志，而 NOT 不会（如果您想执行按位操作而不影响依赖于先前操作标志的跳转条件，有时很有用） 。现在，考虑到您不是直接编写程序集，您确实无法以有意义的方式访问此标志，因此我怀疑这就是偏爱其中一个的原因。

他的评论让我很好奇以下代码是否会产生相同的汇编指令

#include <iostream>

int main()
{
    unsigned int val = 0;

    std::cout << "Enter a numeric value: ";
    std::cin >> val;

    if ( (val ^ ~0U) == 0)
    {
        std::cout << "Value inverted is zero" << std::endl;
    } else
    {
        std::cout << "Value inverted is not zero" << std::endl;
    }

    if ( (~val) == 0)
    {
        std::cout << "Value inverted is zero" << std::endl;
    } else
    {
        std::cout << "Value inverted is not zero" << std::endl;
    }

    return 0;
}

对于以下两个操作

if ( (val ^ ~0U) == 0 )

and

if ( (~val) == 0 )

The 未优化Visual Studio 2010 中的 build 给出以下反汇编：

    if ( (val ^ ~0U) == 0)
00AD1501  mov         eax,dword ptr [val]  
00AD1504  xor         eax,0FFFFFFFFh  
00AD1507  jne         main+86h (0AD1536h)  


    if ( (~val) == 0)
00AD1561  mov         eax,dword ptr [val]  
00AD1564  not         eax  
00AD1566  test        eax,eax  
00AD1568  jne         main+0E7h (0AD1597h)  

我的问题是关于优化的。是不是写得比较好

if ( (val ^ ~0U) == 0)

or

if ( (~val) == 0)

这取决于很多因素，但主要取决于您告诉编译器要优化的内容（如果有的话）。

如果编译器设置为优化大小（最小字节码），那么有时它会使用XOR在看似奇怪的地方。例如，X86使用的可变长度编码方案可以设置一个寄存器来0 by XOR'ing 本身的代码字节数比使用所需的代码少MOV操作说明。

考虑使用的代码XOR:

if ( (val ^ ~0U) == 0 )  /* 3-bytes to negate and test (x86) */

    XOR eax,0FFFFFFFFh需要 3 个字节AND设置/清除零标志 (ZF)

现在，考虑使用的代码NOT:

if ( (~val) == 0)        /* 4-bytes to negate and test (x86) */

    NOT eax被编码成2字节指令，但不影响CPU标志。

    TEST eax,eax添加额外的 2 个字节，并且需要设置/清除零标志 (ZF)

NOT也是一个简单的指令，但由于它不影响任何CPU标志，因此您必须发出TEST之后指示使用它进行分支，如代码中所示。这实际上会产生更大的字节码，因此设置为优化大小的智能编译器将probably尽量避免使用NOT。这两条指令一起完成所需的周期数因 CPU 代的不同而异，并且当智能编译器被告知优化速度时，也会将其纳入其决策中。

---

If you are not writing hand-tuned assembly, it is best to use whatever is clearest to a human and hope that the compiler is smart enough to choose different instructions/scheduling/etc. to optimize for size/speed as requested at compile-time. Compilers have a smart set of heuristics they use to choose and schedule instructions, they know more about the target CPU architecture than the average coder.

如果您后来发现这个分支确实是一个瓶颈，并且没有更高级别的方法来解决该问题，那么您可以进行一些低级别的调整。然而，如今，除非您的目标是低功耗嵌入式 CPU 或内存有限的设备，否则这是一件微不足道的事情。我通过手动调整来挤出足够的性能以使其值得的唯一地方是受益于数据并行性的算法，并且编译器不够智能，无法有效地利用 MMX/SSE 等专用指令集。