assembly - 是 mov rax,0x12345678; jmp rax 仍然会杀死分支预测吗？

Question

我无法找到上述两种情况的具体信息，尽管听取了您的专家意见。

第一件事是:我知道间接 jmp 会损害分支预测，并且即使间接结果恒定，它仍然需要预测维护缓冲区和其他内容，所有这些都与绝对 jmp 相比。

我的问题是，如果有人知道:

mov rax, 1234567812345678h;
jmp rax;

仍然被处理器的分支预测器认为是间接的，或者在这种情况下它是否进行数学运算..我这样做是因为 x64 没有直接的“jmp Absolute 64”指令，只有间接指令。 :/(How to execute a call instruction with a 64-bit absolute address? 建议这样做，如果您不能将跳转放置得足够靠近目标并使用 jmp rel32。)

<小时/>

其次，在这个程度上，jmp 0x1234 和 call 0x1234 之间是否有任何真正的区别(在处理器优化方面(指令缓存、预取器及其提示、分支预测))？ (vc2012“速度优化”产生调用，“min_size opt”产生jmp，“混合优化”产生x64的jmp，x86的调用)

Answer 1

英特尔的分支目标(和分支)预测非常复杂，并且是严格保密的商业 secret 。不一定只有一种算法，也就是说，不同 CPU 的预测机制会有所不同；这取决于英特尔想要为给定处理器解决问题的晶体管数量。当然，除了英特尔之外，还有其他 x86 和 x64 处理器制造商。

历史分支目标预测机制(使用过去运行的相同指令来预测后续执行的目标)几乎肯定会预测该分支的正确目标，因为只有一个目标。因此，如果重新执行该代码序列(例如在循环中)并且它在指令缓存中保留一段时间，那么它可能会得到很好的处理。 (但是，在某些处理器上，如果其他地方发生另一个分支导致哈希冲突，则分支目标预测机制可能会通过与缓存行冲突类似的效果而被抵消。)

一个更大的问题可能是，如果这样的序列大量出现在新加载到缓存中的代码中，那么它的处理效果如何，这涉及到处理器的非基于历史的目标预测功能。这种(非历史)分支目标预测可以轻松地确定给定此代码序列的分支位置，尽管这完全取决于制造商是否认为它值得任何给定处理器的芯片上的实际空间。做出此类决定的因素包括功耗、权衡其他性能改进(即可能更好地利用相同芯片区域)以及此类和各种其他代码序列的预期频率。