In “Intel CPU 中的 MicroFusion。”作者：丹尼斯·巴赫瓦洛夫 https://easyperf.net/blog/2018/02/15/MicroFusion-in-Intel-CPUs， 他说：
Unlamination for SandyBridge is described in Intel® 64 and IA-32 Architectures Optimization Reference Manual in chapter “2.3.2.4: Micro-op Queue and the Loop Stream Detector (LSD)”:
微操作队列为某些指令类型提供解码后功能。特别是，与计算操作和所有存储相结合的加载，当与索引寻址一起使用时，在解码器或解码 ICache 中表示为单个微操作。在微操作队列中，它们通过称为取消分层的过程被分成两个微操作，一个执行加载，另一个执行操作
And in 黑客新闻主题 https://news.ycombinator.com/item?id=16304415#16305542，BeeOnRope 指出：
当指令在解码时融合，但在重命名之前“未层压”时，它通常具有与根本不融合类似的性能（但它确实节省了 uop 缓存中的空间），因为 RAT 更有可能成为性能限制。
在这种情况下，为什么要使用未层压代替指令解码时使用更多μops？看起来没有必要吗？
还是因为给定的μop是否应该unlamination在解码阶段是不确定的，需要根据运行时的CPU使用情况动态确定？
微融合+非层压在大部分前端都获得了微融合的吞吐量优势，只是在问题/重命名时失去了它。如果没有这种好处，更多的代码可能会在管道的早期部分遇到瓶颈，尤其是传统解码，其中任何多微指令指令都必须在一个“复杂”解码器中解码，而不是在任何“简单”解码器中解码。https://www.realworldtech.com/sandy-bridge/4/ https://www.realworldtech.com/sandy-bridge/4/
Sandybridge-family simplified the uop format for the out-of-order parts of the back-end (ROB and RS)1; fewer transistors for the same number of ROB entries saves power in a power-intensive part of the CPU. The ROB has to keep track of whether both uops have finished executing, and is dealing with physical register numbers since register-rename has already happened on issue/rename/allocate.
对我来说，解码是值得的vaddps ymm0, ymm1, [rdi+rdx*4]到解码器和微指令缓存中的单个微指令，然后取消层压，而不是首先不熔合。
在解码器中，只有一个复杂解码器可以产生超过 1 个 uop，因此任何尚未恰好位于其解码组中第一个的多 uop 指令都会提前结束该组。使用索引寻址模式拥有一堆带有内存操作数的指令可能会削弱传统解码吞吐量，因为每个这样的指令都会自行解码，需要复杂的解码器。
在uop缓存中，节省空间是有意义的；每“行”6 个 uop 并不是很大，多条指令的额外 uop 很容易需要同一 32 字节块的额外“行”，从而降低缓存密度，从而降低命中率。与 ROB 不同的是，它只需要作为块的一部分获取，无需索引即可让完成端口将其标记为“完成”并准备退出。
英特尔确实对 Haswell 进行了更改，以允许保持更多指令微融合：具有 2 个操作数和读+写目标的指令可以保持索引寻址模式微融合，例如addps xmm0, [rdi + rdx*4]。但不是vaddps xmm0, xmm0, [rdi+rdx*4]， 很遗憾。看微融合和寻址模式 https://stackoverflow.com/questions/26046634/micro-fusion-and-addressing-modes
因此，显然他们意识到或决定值得在 ROB 条目上多花一些位来减少大量代码中的未分层。很多时候 CPU 都在运行标量代码，其指令如下add rdx, [rsi+rcx] or mov [rdi + rcx*4], eax（在 Intel CPU 上，存储是存储地址 + 存储数据微指令，每个写入存储缓冲区条目的一部分），而不是 AVX。此外，Haswell uop 格式必须更改以适应具有 3 个输入的单 uop FMA；在此之前，英特尔微指令最多可以有 2 个输入。 （直到布罗德韦尔，他们才利用这一点来制作adc and cmov单微操作；也许他们希望通过微代码禁用 FMA 作为一个选项，以防发现错误，因此不想将其硬连接到一些基线 x86 指令的处理方式中，这些指令无法在需要运行的 CPU 中禁用现有的二进制文件。）
还是因为给定的μop是否应该unlamination在解码阶段是不确定的，需要根据运行时的CPU使用情况动态确定？
也许与这个想法有关；在预解码中，指令被引导至适当的解码器。一些操作码总是被引导到复杂的解码器，将它们限制为传统解码的 1/时钟吞吐量，即使该操作码的实例实际上解码为单个 uop。 （至少这是我们最好的解释理论最近的英特尔微架构中的简单解码器可以处理所有 1-μop 指令吗？ https://stackoverflow.com/questions/61980149/can-the-simple-decoders-in-recent-intel-microarchitectures-handle-all-1-%C2%B5op-inst)
如果预解码器必须基于索引寻址模式转向复杂解码器，它们可能会做一些不幸的事情，例如将带有 SIB 的任何 uop 发送到复杂解码器，包括add eax, [rsp+16].
它可能还使部分解码器与 Nehalem 更加相似，如果该指令可能的话，无论寻址模式如何，总是微融合内存操作数。
脚注 1：我不记得在哪里读到过有关英特尔简化后端内部微指令格式的事实。它不在https://www.realworldtech.com/sandy-bridge/ https://www.realworldtech.com/sandy-bridge/所以也许在https://agner.org/optimize/ https://agner.org/optimize/（微架构指南）
