用CMP reg，0 vs或reg，reg测试寄存器是否为零？

Question

cmp al, 0
je done

or al, al
jz done

我知道JE和JZ指令是相同的，而且使用OR给出了一个字节的大小改进。然而，我也关心代码速度。似乎逻辑运算符会比SUB或CMP更快，但我只是想确定一下。这可能是大小和速度之间的权衡，或者是双赢（当然代码会更加不透明）。

Answer 1

是的，在性能上是有区别的。

将寄存器与零进行比较的最佳选择是test reg,reg。它设置标志的方式与cmp reg、0相同，并且¹至少与任何其他方式一样快，代码大小更小。

（更好的情况是，ZF已经由设置reg的指令适当设置，这样您就可以直接分支、setcc或cmovcc了。例如，普通循环的底部通常看起来像dec ecx/jnz.loop_top。大多数x86整数指令“根据结果设置标志”，如果输出是0，则包括ZF=1。）。

null

signed-compare条件还允许您执行jle或jg，查看ZF和SF！=of。

test的编码时间比cmp短，直接为0，除了cmp al,imm8特例仍为两个字节。

即便如此，test还是更好的，因为宏融合的原因（对于jle，在Core2上类似），并且因为根本没有immediate可以通过留下一个插槽来提高uop-cache密度，如果另一条指令需要更多的空间（SnB-family）。

P6系列CPU（PPro/PII到Nehalem）具有有限数量的寄存器读取端口，用于发布/重命名阶段从永久寄存器文件读取“冷”值（不是从运行中指令转发的），但最近写入的值可以直接从ROB中获得。不必要地重写寄存器可能会使其再次存在于转发网络中，以帮助避免寄存器读取停滞。（参见Agner Fog的microarch pdf）。

在P6中，用相同的值重写寄存器以使其保持“热”，实际上对于周围代码的某些情况是一种优化。早期的P6系列CPU根本不能进行宏融合，所以使用和reg（reg代替test）就不会错过这一点。但是Core2（在32位模式下）和Nehalem（在任何模式下）都可以宏熔断test/jcc，所以您错过了这一点。

(和在P6系列中等效于或，但如果您的代码曾经在SandyBridge系列CPU上运行，情况就不那么糟糕了：它可以宏融合和/JCC，但不能宏融合或/JCC。寄存器DEP链中额外的延迟周期仍然是P6的一个缺点，尤其是涉及它的关键路径是主要瓶颈的情况下。）

在早期的P6-family、和reg中，reg可能可以作为默认的code-gen选择，如果该值不是有问题的循环携带的dep链的一部分，而是稍后读取的。或者如果是，但是也有一个特定的寄存器读取延迟，您可以用和reg，reg来修复。

如果您只想测试完整寄存器的低8位，test al，al避免写入部分寄存器，在P6-系列中，部分寄存器与完整EAX/RAX单独重命名。或al，al的情况要糟糕得多，如果您后来阅读EAX或ax：p6系列中的部分寄存器stall（为什么GCC不使用部分寄存器？）

正如注释中指出的那样，或reg,reg习语可能来自8080或a。

在i7-6700k Skylake上（使用perf eventsuops_subsced.any和uops_executed.thread)进行测试：

• MOV reg,[mem]（或MOVZX)+test reg,reg/jnz2个uops在融合域和未使用域中，无论寻址模式如何，或者MOVZX代替MOV。无微保险丝；宏熔断吗。
• CMP字节[RIP+STATIC_VAR]，0+JNE。3个融合，3个未融合。（前端和后端）。相对撕裂+即刻结合防止微融合。它也不宏观熔断。代码较小，但效率较低。
• CMP字节[rsi+rdi]，0（索引地址模式）/JNE3融合，3不融合。解码器中的微熔断器，但在问题/重命名时没有层叠。不进行宏熔断。
• CMP字节[rdi+16]，0+JNE2个融合，3个未融合的UOP。由于寻址方式简单，cmp负载+ALU的微融合确实发生了，但直接阻止了宏融合。和load+test+jnz差不多：更小的代码大小，但多了一个后端uop.

如果寄存器中有0（如果要比较bool则有1)，则可以cmp[mem]、reg/jne用于更少的UOP，低至1个fused-domain，2个unfused。但是RIP相关寻址模式仍然不能进行宏融合。

null