LSD 能否从检测到的循环的下一次迭代中发出 uOP？

我正在研究 Haswell 端口 0 上的分支单元的功能，从一个非常简单的循环开始：

BITS 64
GLOBAL _start

SECTION .text

_start:

 mov ecx, 10000000

.loop:

 dec ecx             ;|
  jz .end            ;| 1 uOP (call it D)

jmp .loop            ;| 1 uOP (call it J)

.end:
 mov eax, 60
 xor edi, edi
 syscall

Using perf我们看到循环以 1c/iter 运行

Performance counter stats for './main' (50 runs):

        10,001,055      uops_executed_port_port_6   ( +-  0.00% )
         9,999,973      uops_executed_port_port_0   ( +-  0.00% )
        10,015,414      cycles:u                    ( +-  0.02% )
                23      resource_stalls_rs          ( +- 64.05% )

我对这些结果的解释是：

• D 和 J 都是并行调度的。
• J 的吞吐量倒数为 1 个周期。
• D 和 J 均得到最优调度。

然而，我们也可以看到 RS 永远不会充满。
它最多可以以 2 uOPs/c 的速率调度 uOP，但理论上可以得到 4 uOPs/c，从而在大约 30 c 内产生完整的 RS（对于大小为 60 个融合域条目的 RS）。

据我了解，应该很少有分支错误预测，并且 uOP 应该全部来自 LSD。
所以我看了一下FE：

     8,239,091      lsd_cycles_active ( +-  3.10% )
       989,320      idq_dsb_cycles    ( +- 23.47% )
     2,534,972      idq_mite_cycles   ( +- 15.43% )
         4,929      idq_ms_uops       ( +-  8.30% )

   0.007429733 seconds time elapsed   ( +-  1.79% )

which confirms that the FE is issuing from the LSD¹.
However, the LSD never issues 4 uOPs/c:

     7,591,866      lsd_cycles_active ( +-  3.17% )
             0      lsd_cycles_4_uops 

My interpretation is that the LSD cannot issue uOPs from the next iteration² thereby only sending D J pairs to the BE each cycle.
Is my interpretation correct?

源代码位于这个存储库.

¹ There is a bit of variance, I think this is due to the high number of iterations that allows for some context switch.
² This is sound quite complex to do in hardware with limited circuits depth.

循环中的所有微指令都是分支（每次迭代 2 个）。我认为 `lsd_cycles_4_uops 为零的原因是重命名器的限制。根据Intel优化手册第2.4.3.1节：

重命名器可以在每个周期分配两个分支，而不是一个 在先前的微架构中对每个周期进行分支。这个可以 消除执行中的一些泡沫。

这是桑迪桥微架构部分的一个小节。但据我所知，这适用于所有后来的微架构。最大重命名吞吐量为每个周期 4 uops。但最多两个微指令可以是分支。因此，在这个所有微指令都是分支的示例中，即使在循环的第一次迭代中，LSD 在任何给定周期也永远无法传送超过 2 个微指令。

因此，每个周期将在 RS 中分配 2 个分支微指令，并且每个周期都可以调度这两个分支微指令（一个谓词采用，一个不采用）。所以RS占用率不会增长。

此限制不会影响程序的性能。每个周期执行 2 个分支 uops，每个周期提供 3 个 IPC，这已经是最佳选择。

我试图找到一个可以捕获由于该限制而导致的分配器停顿的性能事件。事件RESOURCE_STALLS.ANY and UOPS_ISSUED.ANY (with cmask=1 and inv=1）在这种情况下似乎不相关。 @IwillnotexistIdonotexist 建议使用IDQ_UOPS_NOT_DELIVERED.CORE。我在下面展示了性能事件及其所有支持的变体的结果。我还提供了这些事件的正确含义，因为手册是错误的。T表示迭代次数。

IDQ_UOPS_NOT_DELIVERED.CORE：计算分配器未使用的插槽数。如果程序运行 C 个核心周期，则插槽总数为 4*C。测量值几乎等于2*T。由于周期数为T，所以时隙数为4*T，这意味着大约一半的发布时隙没有被利用。

IDQ_UOPS_NOT_DELIVERED.CYCLES_0_UOPS_DELIV.CORE：计算从 IDQ 传送零微指令的周期数。测量值可以忽略不计。

IDQ_UOPS_NOT_DELIVERED.CYCLES_LE_1_UOP_DELIV.CORE：计算从 IDQ 传送最多 1 个微指令的周期数。测量值可以忽略不计。

IDQ_UOPS_NOT_DELIVERED.CYCLES_LE_2_UOP_DELIV.CORE：计算 IDQ 最多发送 2 个 uops 的周期数：测量值几乎等于 T。

IDQ_UOPS_NOT_DELIVERED.CYCLES_LE_3_UOP_DELIV.CORE：统计IDQ最多发送3个uop的周期数：测量值几乎等于T。

因此，由于执行时间几乎等于T个核心周期，我们可以得出结论，在大多数周期中，分配器每个周期仅分配2个uop，这等于调度率。

请注意，Haswell 和 Skylake 中的 RS 持有未融合的微指令。因此每个条目可以容纳一个未融合的微指令。看脚注2。但这在这里并不重要，因为没有微融合。