assembly - 混合使用EVEX和VEX编码方案的代价是什么？

Question

known issue混合使用VEX编码的指令和非VEX指令是一种惩罚，程序员必须意识到这一点。

有一些问题和答案，例如this。解决方案取决于您的编程方式（通常在过渡后应该使用zeroupper。但是我的问题是关于EVEX编码的方案。就没有像_mm512_zeroupper()这样的内在函数而言，使用时似乎没有任何损失VEX编码指令和EVEX编码指令一起使用，但是EVEX为4字节，VEX为3字节，向量长度分别为512位和256位。

因为AVX-512不可用（至少对我而言）。我想问一下何时要混合它们时是否有任何需要注意的地方。

Answer 1

在任何当前CPU上混合使用VEX 128/256或EVEX 128/256/512都不会有任何惩罚，也没有理由期望将来的CPU有任何惩罚。

所有VEX和EVEX编码指令均定义为将目标向量寄存器的高字节清零，无论CPU支持的最大向量宽度为多少。这使得它们对于任何未来的更宽泛的向量而言都是面向未来的，而无需像vzeroupper这样的丑陋东西。



（但是，有一个相关的速度降低：如果您显式地编写ZMM寄存器（而不是通过相应的YMM的隐式零扩展，请参见@BeeOnRope's comments有关编写完整的512位寄存器直到SKx上的vzeroupper具有永久影响）。或XMM寄存器），这会使每个较窄的矢量指令的行为都像是Turbo频率限制的512位指令一样。

没有错误的依赖关系或额外的时钟周期，只是每个时钟周期都没有完整涡轮加速那么短。端口1尚未关闭：我们仍然有3个/秒的vpaddd xmm/ymm。

这是一个“全局”内核范围的状态：一个受污染的zmm0..15寄存器会损害整个内核，只有vzeroupper/all会还原更高的turbo。 （但是据报道写到zmm16..31没问题）。只需使用正常的零扩展XMM YMM VEX或EVEX指令编写受影响的ZMM寄存器的下半部分，就不会使您脱离该“模式” /状态。即使像VEX vpxor或EVEX vpxord之类的清零习惯也无法解决问题。实际上，vpxord zmm0,zmm0,zmm0可能会引起问题，这对于调零习惯来说很奇怪。

用户Mysticial和BeeOnRope（参见注释）执行的两个不同实验表明，SKX的物理寄存器文件具有512位条目。根据矢量PRF大小找到ILP的微基准，发现“ SIMD推测PRF大小约为150到158”，对于256位或512位矢量而言，相同。 （并且，我们知道这对于256位PRF大小来说是正确的，基于Intel已发布的有关Skylake-client的信息并在那里进行了实验。）因此，我们可以排除一种存储架构ZMM寄存器需要2个PRF条目和两倍的PRF条目的模式。读/写端口。

我目前对一个解释的猜测是，可能在调度程序上比主向量PRF在物理上距离更远的上层256个PRF，或者只是在主向量PRF中共享相同索引的额外宽度。如果upper256 PRF通电，光速传播延迟可能会限制最大涡轮增压。此硬件设计假设无法用软件进行测试，但仅与vzeroupper / vzeroall脱离不良状态兼容（如果我是对的，请关闭PRF的upper256部分的电源，因为那一条指令让我们知道它尚未使用）。我不确定为什么zmm16..31对此无关紧要。

CPU会跟踪高256个部分是否为非零，因此xsaveopt可以使用更紧凑的块。在中断处理程序中可以与内核的xsaveopt / restore进行交互，但是大多数情况下，我提到它只是CPU跟踪此事件的另一个原因。

请注意，此ZMM脏污上部问题不是由于VEX和EVEX混合引起的。如果对所有128位和256位指令都使用EVEX编码，则会遇到同样的问题。问题在于，在第一代AVX512 CPU上，将512位与较窄的向量混合在一起，其中512位只是一小部分，它们针对较短的向量进行了更优化。 （端口1关闭，并且端口5 FMA的等待时间更长）。

我想知道这是否是故意的，还是设计错误。





在AVX512代码中尽可能使用VEX是一件好事。

VEX与EVEX相比节省了代码大小。有时在拆包或在元素宽度之间转换时，您可能会得到较窄的向量。

（即使上面的问题是将512位和较短的向量混合在一起，128/256位指令也并不比其512位等效指令差。在不应该的情况下，它们会使最大turbo减小，仅此而已。）

VEX编码的vpxor xmm0,xmm0,xmm0已经是将ZMM寄存器清零的最有效方法，与vpxord zmm0,zmm0,zmm0相比节省了2个字节，并且运行速度至少与之相同。 MSVC已经这样做了一段时间，而在我reported the missed optimization之后，clang 6.0（trunk）也这样做了。 （gcc vs. clang on godbolt。

即使没有代码大小，在将来的CPU中将512b指令拆分为两个256b op的速度可能也会更快。 （请参阅关于Is vxorps-zeroing on AMD Jaguar/Bulldozer/Zen faster with xmm registers than ymm?的Agner Fog的答案）。

同样，第一步，水平和应缩小到256b，然后缩小到128b，因此它们可以使用较短的VEX指令，而在某些CPU上，128b指令的使用率较小。同样，车道内的洗牌通常比过马路更快。





SSE / AVX为什么出现问题的背景

另请参阅Agner Fog's 2008 post on the Intel forums，以及在首次发布时对AVX设计进行注释的其余线程。他正确地指出，如果英特尔在最初设计SSE时曾计划扩展到更宽的向量，并提供了一种保存/恢复完整向量的方法，而不论其宽度如何，那么这将不是问题。

同样有趣的是，Agner在2013年对AVX512发表评论，并在英特尔论坛上进行了讨论：AVX-512 is a big step forward - but repeating past mistakes!



首次引入AVX时，他们本可以将旧版SSE指令的行为定义为将上通道清零，这样可以避免对vzeroupper的需要，并且可以保存上层状态（或错误的依赖性）。

调用约定将仅允许函数破坏向量regs的较高通道（就像当前的调用约定一样）。

问题是内核中不支持AVX的代码异步破坏了上层通道。操作系统已经需要支持AVX才能保存/恢复完整矢量状态，并且AVX指令会出错if the OS hasn't set a bit in an MSR that promises this support。因此，您需要一个支持AVX的内核才能使用AVX，这是什么问题？

问题基本上是传统的纯二进制Windows设备驱动程序，它使用传统的SSE指令“手动”手动保存/恢复某些XMM寄存器。如果这样做隐式清零，则将破坏用户空间的AVX状态。

英特尔设计AVX并非使AVX不安全，无法在使用此类驱动程序的Windows系统上启用，而是使旧版SSE版本使上层通道保持不变。让不支持AVX的SSE代码有效运行需要某种惩罚。

我们拥有适用于Microsoft Windows的仅二进制软件发行版，以感谢Intel决定施加SSE / AVX过渡处罚的痛苦。

Linux内核代码必须围绕代码向量regs调用kernel_fpu_begin / kernel_fpu_end，这会触发常规的保存/恢复代码，该代码必须了解AVX或AVX512。因此，任何支持AVX的内核都将在每个要使用SSE或AVX的驱动程序/模块（例如RAID5 / RAID6）中都支持它，甚至是不支持AVX的仅二进制内核模块（假设它是正确编写的，而不是正确编写的）保存/恢复一对xmm或ymm规则本身）。

Windows has a similar future-proof save/restore mechanism，KeSaveExtendedProcessorState，使您可以在内核代码中使用SSE / AVX代码（但不能使用中断处理程序）。 IDK为什么驾驶员不总是使用它；为什么？也许它很慢，或者一开始并不存在。如果它已经足够长的时间可用，那纯粹是二进制驱动程序编写者/发行者的错，而不是Microsoft本身。

（关于OS X的IDK也是。如果二进制驱动程序“手动”保存/恢复xmm regs，而不是告诉OS下一个上下文切换需要恢复FP状态以及整数，那么它们也是问题的一部分。）