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

Question

英特尔推送微码更新以修复名为“Jump Conditional Code (JCC) Erratum”的错误。由于在某些情况下禁用将代码放入 ICache，更新微码导致某些操作效率低下。

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

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

在 /QIntel-jcc-erratum 下，编译器检测跨越或结束于 32 字节边界的跳转和宏融合跳转指令。

问题是：

• 是否有理由将 JCC 与其他跳跃分开处理？
• 是否有理由将提到的宏融合 JCC 与其他 JCC 分开处理？

Answer 1

必须单独提及宏融合跳转，因为这意味着整个cmp/jcc 或任何容易受到这种减速影响的地方，如果cmp 触及边界而jcc 本身没有触及边界。因为 uop 缓存对于这两个 x86 机器指令将有一个 uop，以及非跳转指令的起始地址。

如果每个人都只说“跳跃”，您会认为只有 JCC / JMP / CALL / RET 本身必须避免触及 32B 边界。所以强调与宏观融合的交互是一件好事。

---

这种减速（对于所有跳转）是微码缓解/解决硬件设计缺陷的结果。 无法对触及 32 字节边界的缓存跳转进行 uop-cache 缓存跳转并不是最初的错误，而是治愈的副作用。

最初的勘误描述并没有说明只影响条件分支。即使只有条件分支才是真正的问题，但不幸的是，英特尔可以找到的通过微码更新使其安全的最佳方法可能会影响所有跳转。

例如，在 Skylake-Xeon (SKX) 中，原始勘误表在英特尔的"spec update" errata list for that uarch 中记录为 SKX102：

SKX102. 处理器在复杂序列上的行为可能无法预测 涉及跨越 64 字节边界的分支的条件

问题：在涉及分支指令字节的复杂微架构条件下， 跨越多个 64 字节边界（跨缓存线），不可预测的系统行为 可能会发生。

含义：当出现这种错误时，系统可能会出现不可预测的行为。

解决方法：BIOS 可能包含此错误的解决方法。 [IE。微码更新]

状态：没有修复。

---

我怀疑“JCC 勘误”这个名字很流行，因为“热”代码路径中的大多数分支都是有条件的。编译器通常可以避免将无条件采用的分支放在快速路径中。所以很可能人们首先注意到了 JCC 指令的性能问题，即使它不准确，这个名字也只是卡住了。

顺便说一句，32-byte aligned routine does not fit the uops cache 有您链接的英特尔 PDF 中相关图表的屏幕截图，以及有关性能影响的其他一些链接和详细信息。