¿Cómo funcionan exactamente los registros parciales en Haswell/Skylake? Escribir AL parece tener una falsa dependencia de RAX y AH es inconsistente

Otras respuestas son bienvenidas para abordar Sandybridge e IvyBridge con más detalle. No tengo acceso a ese hardware.

No he encontrado ninguna diferencia de comportamiento de registro parcial entre HSW y SKL. En Haswell y Skylake, todo lo que he probado hasta ahora es compatible con este modelo:

AL nunca cambia de nombre por separado de RAX (o r15b de r15). Entonces, si nunca tocas los registros altos 8 (AH/BH/CH/DH), todo se comporta exactamente como en una CPU sin cambio de nombre de registro parcial (por ejemplo, AMD).

El acceso de solo escritura a AL se fusiona con RAX, con dependencia de RAX. Para cargas en AL, este es un uop de carga ALU+ microfusionado que se ejecuta en p0156, que es una de las pruebas más sólidas de que realmente se está fusionando en cada escritura, y no solo haciendo una doble contabilidad elegante como especuló Agner.

Agner (e Intel) dicen que Sandybridge puede requerir una fusión para AL, por lo que probablemente se le cambie el nombre por separado de RAX. Para SnB, el manual de optimización de Intel (sección 3.5.2.4 Bloqueos parciales del registro) dice

SnB (no necesariamente uarches posteriores) inserta un uop fusionado en los siguientes casos:

• Después de escribir en uno de los registros AH, BH, CH o DH y antes de la siguiente lectura del formato de 2, 4 u 8 bytes del mismo registro. En estos casos se inserta una microoperación de fusión. La inserción consume un ciclo de asignación completo en el que no se pueden asignar otras microoperaciones.

• Después de una microoperación con un registro de destino de 1 o 2 bytes, que no es una fuente de la instrucción (o la forma más grande del registro), y antes de una lectura siguiente de una forma de 2, 4 u 8 bytes del mismo registro. En estos casos, la microoperación de fusión es parte del flujo .

Creo que están diciendo que en SnB, add al,blRMW hará el RAX completo en lugar de cambiarle el nombre por separado, porque uno de los registros fuente es (parte de) RAX. Supongo que esto no se aplica a una carga como mov al, [rbx + rax]; raxen modo de direccionamiento probablemente no cuente como fuente.

No he probado si los uops de fusión de High8 todavía tienen que emitir/cambiar el nombre por sí solos en HSW/SKL. Eso haría que el impacto frontal sea equivalente a 4 uops (ya que ese es el ancho de la tubería de emisión/cambio de nombre).

• No hay forma de romper una dependencia que involucre AL sin escribir EAX/RAX. xor al,alNo ayuda, y tampoco mov al, 0.
• movzx ebx, altiene latencia cero (renombrado) y no necesita unidad de ejecución. (es decir, trabajos de eliminación de movimientos en HSW y SKL). Activa la fusión de AH si está sucio , lo cual supongo que es necesario para que funcione sin una ALU. Probablemente no sea una coincidencia que Intel haya abandonado el cambio de nombre de low8 en el mismo uarch que introdujo la eliminación de movimientos. (La guía de microarcos de Agner Fog tiene un error aquí al decir que los movimientos extendidos a cero no se eliminan en HSW o SKL, solo IvB).
• movzx eax, alno se elimina al cambiar el nombre. La eliminación de movimientos en Intel nunca funciona para lo mismo. mov rax,raxtampoco se elimina, aunque no tiene que extender nada a cero. (Aunque no tendría sentido darle soporte de hardware especial, porque simplemente no es operativo, a diferencia de mov eax,eax). De todos modos, prefiera moverse entre dos registros arquitectónicos separados al realizar la extensión cero, ya sea con un archivo de 32 bits movo de 8 bits movzx.
• movzx eax, bxno se elimina al cambiar el nombre en HSW o SKL. Tiene latencia 1c y utiliza ALU uop. El manual de optimización de Intel sólo menciona la latencia cero para movzx de 8 bits (y señala que movzx r32, high8nunca se le cambia el nombre).

Los registros High-8 se pueden cambiar de nombre por separado del resto del registro y es necesario fusionarlos.

• Acceso de solo escritura ahcon AH mov ah, reg8o mov ah, [mem8]cambio de nombre, sin dependencia del valor anterior, a diferencia de mov-immediate. Ambas son instrucciones que normalmente no necesitarían una ALU uop para la versión de 32 bits. (Pero nomov ah, bl se elimina; necesita una ALU uop p0156, por lo que podría ser una coincidencia).
• un RMW de AH (como inc ah) lo ensucia (por lo que se le cambia el nombre por separado y necesita una fusión uop si se lee AX, EAX o RAX más tarde, incluso como parte de la escritura de AX).
• setcc ahDepende del viejo ah, pero aún así lo ensucia. Creo que mov ah, imm8es lo mismo, pero no he probado tantos casos extremos.

(Inexplicable: un bucle que involucra setcc aha veces puede ejecutarse desde el LSD, vea el rcrbucle al final de esta publicación. Tal vez, siempre que ahesté limpio al final del bucle, ¿puede usar el LSD?).

Si ahestá sucio, setcc ahse fusiona con el archivo renombrado ah, en lugar de forzar una fusión con el archivo rax. por ejemplo %rep 4( inc al/ test ebx,ebx/ setcc ah/ inc al/ inc ah) no genera uops fusionados y solo se ejecuta en aproximadamente 8.7c (latencia de 8 inc alralentizada por conflictos de recursos de los uops para ah. También la cadena inc ah/ setcc ahdep).

Creo que lo que sucede aquí es que setcc r8siempre se implementa como lectura-modificación-escritura. Intel probablemente decidió que no valía la pena tener un setccuop de solo escritura para optimizar el setcc ahcaso, ya que es muy raro que el código generado por el compilador sea setcc ah. (Pero vea el enlace de Godbolt en la pregunta: clang4.0 -m32lo hará).

• La lectura de AX, EAX o RAX desencadena una fusión uop (que ocupa el problema de front-end/cambia el nombre del ancho de banda). Probablemente, la RAT (Tabla de asignación de registros) rastrea el estado de alta suciedad de 8 para la arquitectura R[ABCD]X, e incluso después de que se retira una escritura en AH, los datos de AH se almacenan en un registro físico separado de RAX. Incluso con 256 NOP entre escribir AH y leer EAX, hay una fusión adicional. (Tamaño de ROB = 224 en SKL, por lo que esto garantiza que se mov ah, 123retiró). Detectado con contadores de rendimiento uops_issued/executed, que muestran claramente la diferencia.

• La lectura, modificación y escritura de AL (p. ej. inc al) se fusiona de forma gratuita, como parte de ALU uop. (Solo probado con algunos uops simples, como add/ inc, no div r8o mul r8). Nuevamente, no se activa ninguna fusión uop incluso si AH está sucio.

• La escritura de solo en EAX/RAX (como lea eax, [rsi + rcx]o xor eax,eax) borra el estado sucio de AH (sin fusionar uop).

• La escritura de solo en AX ( mov ax, 1o mov ax, bx) activa primero una fusión de AH. Supongo que en lugar de usar una carcasa especial, se ejecuta como cualquier otro RMW de AX/RAX.

• xor ah,ahtiene una latencia de 1c, no interrumpe el almacenamiento y aún necesita un puerto de ejecución. mov ah,0es el mismo; al igual que con setcc, quizás mov-immediate to 8-bit reg no tenga un formato especial para registros de 8 niveles altos, a diferencia de conmov reg,reg

• La lectura y/o escritura de AL no fuerza una fusión, por lo que AH puede permanecer sucio (y usarse de forma independiente en una cadena de depósito separada). (por ejemplo, add ah, cl/ add al, dlpuede funcionar a 2 IPC, un par por reloj (cuello de botella al agregar latencia).

Ensuciar AH evita que se ejecute un bucle desde el LSD (el búfer de bucle), incluso cuando no hay fusiones de uops. El LSD es cuando la CPU recicla uops en la cola que alimenta la etapa de emisión/cambio de nombre. (Llamado IDQ).

Insertar uops fusionados es un poco como insertar uops de sincronización de pila para el motor de pila. El manual de optimización de Intel dice que el LSD de SnB no puede ejecutar bucles con push/ no coincidentes pop, lo cual tiene sentido, pero implica que puedepush ejecutar bucles con / equilibrado pop. Eso no es lo que estoy viendo en SKL: incluso equilibrado push/ popevita que se ejecute desde el LSD (por ejemplo, push rax/ pop rdx/ times 6 imul rax, rdx​​. (Puede haber una diferencia real entre el LSD de SnB y HSW/SKL: SnB puede simplemente "bloquear" los uops en el IDQ en lugar de repetirlos varias veces, por lo que un bucle de 5 uop tarda 2 ciclos en emitirse en lugar de 1,25 ). De todos modos, parece que HSW/SKL no puede usar el LSD cuando un registro de 8 altos está sucio o cuando contiene uops del motor de pila.

Este comportamiento puede estar relacionado con una errata en SKL :

SKL150: Los bucles cortos que utilizan registros AH/BH/CH/DH pueden provocar un comportamiento impredecible del sistema

Problem: Under complex micro-architectural conditions, short loops of less than 64 instruction that use AH, BH, 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.

This may also be related to Intel's optimization manual statement that SnB at least has to issue/rename an AH-merge uop in a cycle by itself. That's a weird difference for the front-end.

My Linux kernel log says microcode: sig=0x506e3, pf=0x2, revision=0x84. Arch Linux's intel-ucode package just provides the update, you have to edit config files to actually have it loaded. So my Skylake testing was on an i7-6700k with microcode revision 0x84, which doesn't include the fix for SKL150. It matches the Haswell behaviour in every case I tested, IIRC. (e.g. both Haswell and my SKL can run the setne ah / add ah,ah / rcr ebx,1 / mov eax,ebx loop from the LSD). I have HT enabled (which is a pre-condition for SKL150 to manifest), but I was testing on a mostly-idle system so my thread had the core to itself.

With updated microcode, the LSD is completely disabled for everything all the time, not just when partial registers are active. lsd.uops is always exactly zero, including for real programs not synthetic loops. Hardware bugs (rather than microcode bugs) often require disabling a whole feature to fix. This is why SKL-avx512 (SKX) is reported to not have a loopback buffer. Fortunately this is not a performance problem: SKL's increased uop-cache throughput over Broadwell can almost always keep up with issue/rename.

Extra AH/BH/CH/DH latency:

• Reading AH when it's not dirty (renamed separately) adds an extra cycle of latency for both operands. e.g. add bl, ah has a latency of 2c from input BL to output BL, so it can add latency to the critical path even if RAX and AH are not part of it. (I've seen this kind of extra latency for the other operand before, with vector latency on Skylake, where an int/float delay "pollutes" a register forever. TODO: write that up.)

This means unpacking bytes with movzx ecx, al / movzx edx, ah has extra latency vs. movzx/shr eax,8/movzx, but still better throughput.

• Reading AH when it is dirty doesn't add any latency. (add ah,ah or add ah,dh/add dh,ah have 1c latency per add). I haven't done a lot of testing to confirm this in many corner-cases.

Hypothesis: a dirty high8 value is stored in the bottom of a physical register. Reading a clean high8 requires a shift to extract bits [15:8], but reading a dirty high8 can just take bits [7:0] of a physical register like a normal 8-bit register read.

Extra latency doesn't mean reduced throughput. This program can run at 1 iter per 2 clocks, even though all the add instructions have 2c latency (from reading DH, which is not modified.)

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,219,014      uops_executed_thread      # 16349.802 M/sec                 
         1,903      lsd_uops                  #    0.039 M/sec                  

   0.049107358 seconds time elapsed

Some interesting test loop bodies:

%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
    imul  eax, eax
    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

The setcc version (with the %if 1) has 20c loop-carried latency, and runs from the LSD even though it has setcc ah and add ah,ah.

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,009,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% )

Unexplained: it runs from the LSD, even though it makes AH dirty. (At least I think it does. TODO: try adding some instructions that do something with eax before the mov eax,ebx clears it.)

But with mov ah, bl, it runs in 5.0c per iteration (imul throughput bottleneck) on both HSW/SKL. (The commented-out store/reload works, too, but SKL has faster store-forwarding than HSW, and it's variable-latency...)

 #  mov ah, bl   version
 5,009,785,393      cycles                    #    4.289 GHz                      ( +-  0.08% )
 1,000,315,930      branches                  #  856.373 M/sec                    ( +-  0.00% )
11,001,728,338      instructions              #    2.20  insn per cycle           ( +-  0.00% )
12,003,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% )

Notice that it doesn't run from the LSD anymore.

2023 update

Some more tests, still on i7-6700k Skylake, this time with newer microcode (version 0xf0) that permanently disabled the LSD (because of AH-merging correctness issue in corner cases, apparently.)

.loop:
   times 6 mov ah, cl   ; or as low as times 3.  But times 7 makes the loop slower, 4c / iter
    mov ax, bx          ; trigger an AH merge
    dec ebp
    jnz .loop
.end:

• With times 1 or times 2 mov ah, cl: 2 cycles / iter.
  (4 or 5 uops issued and executed / iter)
• With times 3 to times 6 mov ah, cl: 3 cycles / iter
  (6 to 10 uops issued and executed)
• With times 7 to times 10 mov ah, cl: 4 cycles / iter

The bottleneck with mov ah, cl is I think front-end throughput. An AH-merging uop needing to issue in a cycle by itself would explain this, e.g. an upper limit of 5 uops in 2 cycles, with 4 in one cycle, 1 in the other. And increasing by 1 cycle for each 4 more uops. That front-end bubble for the AH-merging uop should give the uop cache time to keep up.

Esto también demuestra mov ah, clque no depende del antiguo RAX después de la fusión: si hubiera una dependencia de salida, no podría ejecutarse más rápido que 1 instrucción por ciclo (sin contar dec/jne).

Pero xor ah,ahor mov ah,0crea una cadena de dependencia transmitida por bucle, exactamente como inc ah, lo que confirma que mov ax, bxtiene una dependencia de AH. Limita la velocidad a n+3 ciclos por iteración, donde nestá la longitud de la times n mov ah,0cadena. Por ejemplo, times 7se necesitan 10 ciclos, con 10 uops emitidos y ejecutados. (De 10 instrucciones, incluido un dec/jne fusionado con macro, por lo que hay un uop adicional allí).

Parece que el costo de latencia del uop de fusión de AH es de 1 ciclo, y el mov ax, bxcosto de otro ciclo para fusionar un nuevo valor en la parte inferior de RAX. El ciclo adicional se produce al leer AH después de escribir RAX. Agregar a mov ah, almantiene la dependencia de RAX, pero sin leer AH.

Aug 13 '2017 12:08 Peter Cordes