为什么 SSE 指令保留 YMM 寄存器的高 128 位？

Question

似乎recurring problem 许多英特尔处理器（直到 Skylake，除非我错了）在将 AVX-256 指令与 SSE 指令混合时表现出较差的性能。

根据Intel's documentation，这是由于 SSE 指令被定义为保留 YMM 寄存器的高 128 位，因此为了能够通过不使用 AVX 数据路径的高 128 位来节省功耗， CPU 在执行 SSE 代码时将这些位存储起来，并在输入 AVX 代码时重新加载它们，存储和加载成本很高。

但是，我找不到明显的原因或解释为什么 SSE 指令需要保留那些高 128 位。相应的 128 位 VEX 指令（使用它可以避免性能损失）通过始终清除 YMM 寄存器的高 128 位而不是保留它们来工作。在我看来，当英特尔定义 AVX 架构时，包括将 XMM 寄存器扩展到 YMM 寄存器时，他们可以简单地定义 SSE 指令也将清除高 128 位。显然，由于 YMM 寄存器是新的，因此不可能有依赖于 SSE 指令保留这些位的遗留代码，而且在我看来，英特尔也很容易看到这一点。

那么，Intel 定义 SSE 指令以保留 YMM 寄存器的高 128 位的原因是什么？有用吗？

Answer 1

为了在站内移动外部资源，我从the link Michael provided in the comments中提取了相关段落。

所有功劳归他所有。
该链接指向 Agner Fog 在英特尔论坛上提出的一个非常相似的问题。

[Fog in response to Intel's answer]如果我理解你的话，你决定有必要拥有所有 128 位指令的两个版本以避免 破坏 YMM 寄存器的上部，以防中断使用旧版 XMM 指令调用设备驱动程序。

英特尔担心，通过使传统 SSE 指令将 XMM 寄存器的上部归零，ISR 现在会突然 影响新的 YMM 寄存器。
如果不支持保存新的 YMM 上下文，这将使得在任何情况下都无法使用 AVX 情况。

但是 Fog 并不完全满意，并指出只需使用支持 AVX 的编译器重新编译驱动程序（这样 VEX 指令被使用）将导致相同的结果。

英特尔回复说，他们的目标是避免强迫现有软件 重写。

我们无法强制行业重写/修复所有现有驱动程序（例如使用 XSAVE），也无法保证他们会成功完成此操作。例如，考虑一下行业在从 32 位操作系统过渡到 64 位操作系统时仍在经历的痛苦！我们从操作系统供应商那里得到的反馈也排除了增加 ISR 服务的开销以增加每个中断的状态管理开销。我们不想将这些成本中的任何一项都施加到甚至通常不使用宽向量的行业部分。

通过有两个版本的指令，可以像支持 FPU/SSE 一样在驱动程序中实现对 AVX 的支持：

给出的示例类似于当前的场景，即 ring-0 驱动程序 (ISR) 供应商尝试使用浮点状态，或意外将其链接到某些库中，在不自动管理 Ring- 上下文的操作系统中0。这是众所周知的错误来源，我只能提出以下建议：

• 在这些操作系统上，不鼓励驱动程序开发人员使用浮点或 AVX

• 应鼓励驱动程序开发人员在驱动程序验证期间禁用硬件功能（即，Ring-0 中的驱动程序可以通过 XSETBV() 禁用 AVX 状态

Answer 2

背景：我们很早就决定让 KeSaveFloatingPointState 在 Windows x64 上什么都不做，并允许使用 XMM 寄存器而无需额外的保存/恢复调用，即使在驱动程序中也是如此。显然，这些驱动程序不会知道 AVX 或 YMM 寄存器。