汇编 – Haswell/Skylake的部分寄存器究竟如何执行？写AL似乎对R

我没有发现HSW和SKL之间存在任何部分注册行为差异。
在Haswell和Skylake上，到目前为止我测试的所有内容都支持这个模型：

AL永远不会与RAX(或r15中的r15b)分开重命名。因此，如果您从未触摸过high8寄存器(AH / BH / CH / DH)，那么所有内容的行为与没有部分注册重命名的CPU(例如AMD)完全相同。

对AL的只写访问权限合并到RAX中，并依赖于RAX。对于加载到AL的负载，这是一个微融合的ALU加载uop，它在p0156上执行，这是它在每次写入时真正合并的最有力的证据之一，而不仅仅是像Agner推测的那样进行一些花哨的双重记录。

Agner(和英特尔)称Sandybridge可能需要合并用于AL的uop，因此它可能与RAX分开重命名。对于SnB，Intel’s optimization manual (section 3.5.2.4 Partial Register Stalls)说

SnB (not necessarily later uarches) inserts a merging uop in the following cases:

• After a write to one of the registers AH,BH,CH or DH and before a
  following read of the 2-,4- or 8-byte form of the same register. In
  these cases a merge micro-op is inserted. The insertion consumes a
  full allocation cycle in which other micro-ops cannot be allocated.

• After a micro-op with a destination register of 1 or 2 bytes,which is
  not a source of the instruction (or the register’s bigger form),and
  before a following read of a 2-,4- or 8-byte form of the same
  register. In these cases the merge micro-op is part of the flow.

我认为他们说在SnB上，添加al，bl将RMW完整的RAX而不是单独重命名，因为其中一个源寄存器是(部分)RAX。我的猜测是，这不适用于像mov al，[rbx rax];寻址模式下的rax可能不算作源。

我还没有测试过high8合并uops是否仍然需要在HSW / SKL上自行发布/重命名。这将使前端影响相当于4 uops(因为那是问题/重命名管道宽度)。

>如果不编写EAX / RAX，就无法打破涉及AL的依赖关系。 xor al，al没有帮助，mov al，0也没有。
> movzx ebx，al有zero latency (renamed)，不需要执行单元。 (即，对HSW和SKL进行移动消除)。如果它很脏，它会触发AH的合并，我认为这是没有ALU工作所必需的。英特尔在引入mov-elimination的同一个uarch中降低了8的重命名，这可能并非巧合。 (Agner Fog的微型指南在这里有一个错误，他说在HSW或SKL上没有消除零扩展动作，只有IvB。)
> movzx eax，al在重命名时不会被删除。英特尔的mov-elimination永远不会同样适用。 mov rax，rax也没有被淘汰，即使它不需要对任何东西进行零扩展。 (虽然没有必要给它特殊的硬件支持，因为它只是一个无操作，不像mov eax，eax)。无论如何，当零扩展时，更喜欢在两个独立的架构寄存器之间移动，无论是32位mov还是8位movzx。
>在HSW或SKL上重命名时，不会删除> movzx eax，bx。它具有1c延迟并使用ALU uop。英特尔的优化手册仅提到了8位movzx的零延迟(并指出movzx r32，high8永远不会重命名)。

高8寄存器可以与寄存器的其余部分分开重命名，并且需要合并uop。

>只写访问啊用mov啊，r8或者mov啊，[mem]做重命名AH，不依赖于旧值。这些都是通常不需要ALU uop的指令(对于32位版本)。
>一个RM的AH(像公司啊)弄脏了它。
> setcc啊取决于老啊，但还是很脏。我觉得mov啊，imm8是一样的，但还没有测试过多少个角落的情况。

(不明原因：一个涉及setcc的循环啊有时候可以从LSD运行，请看这个帖子末尾的rcr循环。也许只要在循环结束时干净啊，它可以使用LSD吗？)。

如果啊是脏的，setcc啊合并到重命名啊，而不是强制合并到rax。例如％rep 4(包括/ test ebx，ebx / setcc啊/ inc al / inc啊)没有生成合并的uops，只能在大约8.7c内运行(因为来自uops的资源冲突，8的延迟减慢了8。还有inc啊/ setcc啊dep链)。

我想这里发生的事情是setcc r8总是被实现为读 – 修改 – 写。英特尔可能认为不值得使用只写setcc uop来优化setcc啊的情况，因为编译器生成的代码很少用于setcc啊。 (但请看问题中的godbolt链接：clang4.0与-m32会这样做。)
>读取AX，EAX或RAX会触发合并uop(占用前端问题/重命名带宽)。可能RAT(寄存器分配表)跟踪架构R [ABCD] X的高8脏状态，甚至在写入AH退出之后，AH数据也存储在与RAX不同的物理寄存器中。即使在编写AH和读取EAX之间有256个NOP，也有一个额外的合并uop。 (SKL上的ROB大小= 224，所以这保证了mov ah，123已经退役)。使用uops_issued /执行的perf计数器检测到，这清楚地显示了差异。
>作为ALU uop的一部分，AL的读取 – 修改 – 写入(例如，inc)免费合并。 (仅使用一些简单的uops进行测试，例如add / inc，而不是div r8或mul r8)。同样，即使AH很脏，也不会触发合并的uop。
>只写EAX / RAX(如lea eax，[rsi rcx]或xor eax,eax)清除AH-dirty状态(不合并uop)。
>只写AX(mov ax，1)首先触发AH的合并。我想这不是特殊套管，而是像任何其他RMW AX / RAX一样运行。 (TODO：测试mov ax，bx，虽然这不应该是特殊的，因为它没有被重命名。)
> xor啊，啊有1c延迟，不是dep-breaking，还需要一个执行端口。
>读取和/或写入AL不会强制合并，因此AH可以保持脏(并且可以在单独的dep链中独立使用)。 (例如，添加啊，cl / add al，dl可以每个时钟运行1次(加密等待时间瓶颈)。

使AH变脏可防止循环从LSD(循环缓冲区)运行，即使没有合并的uop。 LSD是指CPU在队列中循环uops以提供问题/重命名阶段。 (称为IDQ)。

插入合并的uops有点像为堆栈引擎插入堆栈同步uops。英特尔的优化手册说，SnB的LSD无法运行具有不匹配的推/弹的循环，这是有道理的，但这意味着它可以运行具有平衡推/弹的循环。这不是我在SKL上看到的：即使是平衡的推/弹也阻止了从LSD运行(例如推rax / pop rdx /次6 imul rax，rdx。(SnB的LSD和HSW / SKL之间可能存在真正的区别： SnB may just “lock down” the uops in the IDQ instead of repeating them multiple times,so a 5-uop loop takes 2 cycles to issue instead of 1.25.)无论如何，当高8寄存器变脏或者包含堆栈引擎微操作时，似乎HSW / SKL不能使用LSD。

此行为可能与an erratum in SKL有关：

07005

Problem: Under complex micro-architectural conditions,short loops of less than 64 instruction that use AH,CH,or DH registers as well as their corresponding wider registers (e.g. RAX,EAX,or AX for AH) may cause unpredictable system behaviour. This can only happen when both logical processors on the same physical processor are active.

这也可能与英特尔的优化手册声明有关，即SnB至少必须在一个循环中自行发布/重命名AH合并uop。对于前端而言，这是一个奇怪的区别。

我的Linux内核日志说微码：sig = 0x506e3，pf = 0x2，revision = 0x84。
Arch Linux的intel-ucode软件包只提供更新，you have to edit config files to actually have it loaded。所以我的Skylake测试是在i7-6700k上进行微码修订版0x84，即doesn’t include the fix for SKL150.它与我测试的每一个案例中的Haswell行为相匹配，IIRC。 (例如Haswell和我的SKL都可以运行setne啊/ add啊，啊/ rcr ebx，1 / mov eax，ebx从LSD循环)。我启用了HT(这是SKL150显示的前提条件)，但我正在测试一个大多数空闲的系统，所以我的线程有自己的核心。

使用更新的微码，LSD完全禁用所有时间，而不仅仅是部分寄存器处于活动状态。 lsd.uops总是正好为零，包括真正的程序而不是合成循环。硬件错误(而不是微码错误)通常需要禁用整个功能来修复。这就是为什么SKL-avx512(SKX)是reported to not have a loopback buffer.幸运的是，这不是性能问题：SKL在Broadwell上的uop-cache吞吐量增加几乎总能跟上问题/重命名。

额外的AH / BH / CH / DH潜伏期：

>当它不脏时(单独重命名)读取AH会为两个操作数增加额外的延迟周期。例如添加bl，ah从输入BL到输出BL的延迟为2c，因此即使RAX和AH不是它的一部分，它也会增加关键路径的延迟。 (我之前看到过另一个操作数的这种额外延迟，在Skylake上有矢量延迟，其中一个int / float延迟会永久地“污染”一个寄存器.TODO：写下来。)

这意味着使用movzx ecx解压缩字节，al / movzx edx，ah与movzx / shr eax，8 / movzx有额外的延迟，但仍然有更好的吞吐量。

>在脏时读取AH不会增加任何延迟。 (加啊，啊还是加啊，dh / add dh，每次加1都有1c延迟)。在很多角落里，我没有做过很多测试来证实这一点。

假设：脏的high8值存储在物理寄存器的底部。读取干净的高电平8需要移位来提取位[15：8]，但读取脏的高电平8只能取物理寄存器的位[7：0]，就像正常的8位寄存器读取一样。

额外延迟并不意味着吞吐量降低。即使所有添加指令都有2c延迟(来自读取DH，未经修改)，该程序每2个时钟可以运行1个iter。

global _start
_start:
    mov     ebp,100000000
.loop:
    add ah,dh
    add bh,dh
    add ch,dh
    add al,dh
    add bl,dh
    add cl,dh
    add dl,dh

    dec ebp
    jnz .loop

    xor edi,edi
    mov eax,231   ; __NR_exit_group  from /usr/include/asm/unistd_64.h
    syscall       ; sys_exit_group(0)

Performance counter stats for './testloop':

     48.943652      task-clock (msec)         #    0.997 CPUs utilized          
             1      context-switches          #    0.020 K/sec                  
             0      cpu-migrations            #    0.000 K/sec                  
             3      page-faults               #    0.061 K/sec                  
   200,314,806      cycles                    #    4.093 GHz                    
   100,024,930      branches                  # 2043.675 M/sec                  
   900,136,527      instructions              #    4.49  insn per cycle         
   800,219,617      uops_issued_any           # 16349.814 M/sec                 
   800,014      uops_executed_thread      # 16349.802 M/sec                 
         1,903      lsd_uops                  #    0.039 M/sec                  

   0.049107358 seconds time elapsed

一些有趣的测试循环体：

%if 1
     imul eax,eax
     mov  dh,al
     inc dh
     inc dh
     inc dh
;     add al,dl
    mov cl,dl
    movzx eax,cl
%endif

Runs at ~2.35c per iteration on both HSW and SKL.  reading `dl` has no dep on the `inc dh` result.  But using `movzx eax,dl` instead of `mov cl,dl` / `movzx eax,cl` causes a partial-register merge,and creates a loop-carried dep chain.  (8c per iteration).


%if 1
    imul  eax,eax
    imul  eax,eax         ; off the critical path unless there's a false dep

  %if 1
    test  ebx,ebx          ; independent of the imul results
    ;mov   ah,123         ; dependent on RAX
    ;mov  eax,0           ; breaks the RAX dependency
    setz  ah              ; dependent on RAX
  %else
    mov   ah,bl          ; dep-breaking
  %endif

    add   ah,ah
    ;; ;inc   eax
;    sbb   eax,eax

    rcr   ebx,1      ; dep on  add ah,ah  via CF
    mov   eax,ebx     ; clear AH-dirty

    ;; mov   [rdi],ah
    ;; movzx eax,byte [rdi]   ; clear AH-dirty,and remove dep on old value of RAX
    ;; add   ebx,eax          ; make the dep chain through AH loop-carried
%endif

setcc版本(带％if 1)有20c循环延迟，并且从LSD运行即使它有setcc啊加啊，啊。

00000000004000e0 <_start.loop>:
  4000e0:       0f af c0                imul   eax,eax
  4000e3:       0f af c0                imul   eax,eax
  4000e6:       0f af c0                imul   eax,eax
  4000e9:       0f af c0                imul   eax,eax
  4000ec:       0f af c0                imul   eax,eax
  4000ef:       85 db                   test   ebx,ebx
  4000f1:       0f 94 d4                sete   ah
  4000f4:       00 e4                   add    ah,ah
  4000f6:       d1 db                   rcr    ebx,1
  4000f8:       89 d8                   mov    eax,ebx
  4000fa:       ff cd                   dec    ebp
  4000fc:       75 e2                   jne    4000e0 <_start.loop>

 Performance counter stats for './testloop' (4 runs):

       4565.851575      task-clock (msec)         #    1.000 CPUs utilized            ( +-  0.08% )
                 4      context-switches          #    0.001 K/sec                    ( +-  5.88% )
                 0      cpu-migrations            #    0.000 K/sec                  
                 3      page-faults               #    0.001 K/sec                  
    20,007,739,240      cycles                    #    4.382 GHz                      ( +-  0.00% )
     1,001,181,788      branches                  #  219.276 M/sec                    ( +-  0.00% )
    12,006,455,028      instructions              #    0.60  insn per cycle           ( +-  0.00% )
    13,009,415,501      uops_issued_any           # 2849.286 M/sec                    ( +-  0.00% )
    12,592,328      uops_executed_thread      # 2630.307 M/sec                    ( +-  0.00% )
    13,055,852,774      lsd_uops                  # 2859.456 M/sec                    ( +-  0.29% )

       4.565914158 seconds time elapsed                                          ( +-  0.08% )

不明原因：它从LSD运行，即使它使AH变脏。 (至少我认为确实如此.TODO：尝试在mov eax之前添加一些与eax做某事的指令，ebx清除它。)

但是对于mov啊，bl，它在HSW / SKL上每次迭代运行5.0c(imul吞吐量瓶颈)。 (已注释掉的商店/重装也有效，但SKL的存储转发速度比HSW快，而且是variable-latency …)

#  mov ah,bl   version
 5,785,393      cycles                    #    4.289 GHz                      ( +-  0.08% )
 1,000,315,930      branches                  #  856.373 M/sec                    ( +-  0.00% )
11,728,338      instructions              #    2.20  insn per cycle           ( +-  0.00% )
12,003,708      uops_issued_any           # 10275.807 M/sec                   ( +-  0.00% )
11,002,974,066      uops_executed_thread      # 9419.678 M/sec                    ( +-  0.00% )
         1,806      lsd_uops                  #    0.002 M/sec                    ( +-  3.88% )

   1.168238322 seconds time elapsed                                          ( +-  0.33% )

请注意，它不再从LSD运行。