assembly - 英特尔 JCC 勘误表 - 真的应该单独对待 JCC 吗？

Question

英特尔推送微码更新以修复名为“跳转条件代码 (JCC) 勘误表”的错误。由于在某些条件下禁用将代码放入 ICache，更新微码导致某些操作效率低下。

已发布文档，标题为 Mitigations for Jump Conditional Code Erratum不仅列出JCC ，它列出了:无条件跳转、条件跳转、宏融合条件跳转、调用和返回。

MSVC 开关 /QIntel-jcc-erratum 文档提到:

Under /QIntel-jcc-erratum, the compiler detects jump and macro-fused jump instructions that cross or end on a 32-byte boundary.

问题是:

是否有理由将 JCC 与其他跳转分开处理？

是否有理由将宏融合 JCC 与其他 JCC 分开处理？

Answer 1

宏融合跳转必须单独提及，因为它意味着整个cmp/jcc如果 cmp 很容易受到这种放缓的影响当 jcc 触及边界时本身没有。因为对于这两条 x86 机器指令，uop 缓存将具有单个 uop，以及非跳转指令的起始地址。
如果每个人都只说“跳跃”，那么您会认为只有 JCC/JMP/CALL/RET 本身必须避免触及 32B 边界。所以突出与macro-fusion的交互是一件好事。

这种减速(对于所有跳转)是硬件设计缺陷的微代码缓解/解决方法的结果。 无法对触及 32 字节边界的缓存跳转进行 uop-cache 跳转并不是最初的错误，而是治愈的副作用。
最初的勘误描述没有说明只影响条件分支。即使只有条件分支才是真正的问题，但遗憾的是，英特尔可以找到通过微码更新使其安全的最佳方式影响了所有跳转。
例如，在 Skylake-Xeon (SKX) 中，原始勘误在 Intel 的 "spec update" errata list for that uarch 中记录为 SKX102 :

SKX102. Processor May Behave Unpredictably on Complex Sequence ofConditions Which Involve Branches That Cross 64 Byte Boundaries

Problem: Under complex micro-architectural conditions involving branch instructions bytes thatspan multiple 64 byte boundaries (cross cache line), unpredictable system behaviormay occur.

Implication: When this erratum occurs, the system may behave unpredictably.

Workaround: It is possible for BIOS to contain a workaround for this erratum. [i.e. a microcode update]

Status: No fix.

我怀疑“JCC 勘误表”这个名字很流行，因为“热”代码路径中的大多数分支都是有条件的。 编译器通常可以避免将无条件采用的分支放在快速路径中。所以很可能人们首先注意到了 JCC 指令的性能问题，即使它不准确，这个名字也只是卡住了。
顺便说一句， 32-byte aligned routine does not fit the uops cache有您链接的英特尔 PDF 中相关图表的屏幕截图，以及有关性能影响的其他一些链接和详细信息。