Comment fonctionnent exactement les registres partiels sur Haswell/Skylake? Écrire AL semble avoir une fausse dépendance sur RAX, et AH est incohérent

Autres réponses bienvenue pour aborder Sandybridge et IvyBridge plus en détail. Je n'ai pas accès à ce matériel.

---

Je n'ai trouvé aucune différence de comportement partielle entre HSW et SKL. Sur Haswell et Skylake, tout ce que j'ai testé jusqu'à présent supporte ce modèle:

AL n'est jamais renommé séparément de RAX (ou r15b à partir de r15). Donc, si vous ne touchez jamais les registres high8 (AH/BH / CH / DH), tout se comporte exactement comme sur un processeur sans partial - Reg renommage (par exemple AMD).

L'accès en écriture seule à AL fusionne dans RAX, avec une dépendance sur RAX. Pour les charges dans AL, il s'agit d'un uop alu+load micro-fusionné qui s'exécute sur p0156, ce qui est l'une des preuves les plus solides qu'il fusionne vraiment à chaque Écriture, et pas seulement faire une double comptabilité comme Agner a spéculé.

Agner (et Intel) disent que Sandybridge peut exiger une uop de fusion pour AL, donc il est probablement renommé séparément de RAX. Par La Bns, manuel d'optimisation D'Intel (section 3.5.2.4 stands de Registre partiel) dit

SnB (pas nécessairement plus tard uarches) insère une UOP fusion dans les cas suivants:

• Après une écriture à L'un des registres AH, BH, CH ou Dh et avant un après lecture de la forme 2, 4 ou 8 octets du même registre. Dans dans ces cas, une fusion micro-op est insérée. l'insertion consomme un cycle d'allocation complet dans lequel d'autres micro-ops ne peuvent pas être alloué.

• Après un micro-op avec un registre de destination de 1 ou 2 octets, qui est pas une source de l'instruction (ou la forme plus grande du registre), et avant une lecture suivante d'une forme de 2, 4 ou 8 octets de la même inscrire. Dans ces cas la fusion micro-op fait partie du flux.

Je pense qu'ils disent que sur SnB, {[5] } va RMW le RAX complet au lieu de le renommer séparément, parce que l'une des sources registres est (partie de) RAX. Je suppose que cela ne s'applique pas à une charge comme mov al, [rbx + rax]; rax dans un mode d'adressage ne compte probablement pas comme source.

Je n'ai pas testé si les uops de fusion high8 doivent toujours émettre / renommer eux-mêmes sur HSW / SKL. Cela rendrait l'impact frontal équivalent à 4 uops (puisque c'est le problème/renommer la largeur du pipeline).

• Il N'y a aucun moyen de briser une dépendance impliquant AL sans écrire EAX / RAX. xor al,al n'aide pas, et ni fait mov al, 0.
• movzx ebx, al a zéro latence (renommé), et a besoin d'aucune unité d'exécution. (i.e. MOV-elimination fonctionne sur HSW et SKL). il déclenche la fusion de AH si c'est sale, ce qui, je suppose, est nécessaire pour que cela fonctionne sans ALU. Ce n'est probablement pas une coïncidence si Intel a abandonné le renommage low8 dans le même uarch qui a introduit l'élimination mov. (Le guide micro-arch d'Agner Fog a une erreur ici, disant que les mouvements étendus à zéro ne sont pas éliminés sur HSW ou SKL, seulement IvB.)
• movzx eax, al est pas éliminé à renommer. mov-élimination sur Intel ne fonctionne jamais pour même. mov rax,rax n'est pas éliminé non plus, même s'il n'a rien à étendre à zéro. (Bien qu'il ne servirait à rien de lui donner un support matériel spécial, car c'est juste un no-op, contrairement à mov eax,eax). Quoi qu'il en soit, préférez se déplacer entre deux registres architecturaux séparés lorsque l'extension zéro, que ce soit avec un mov 32 bits ou un 8 bits movzx.
• movzx eax, bx est pas éliminé au renommage sur HSW ou SKL. Il a une latence 1c et utilise un uop ALU. Le manuel d'optimisation d'Intel ne mentionne que la latence zéro pour movzx 8 bits (et souligne que movzx r32, high8 n'est jamais renommé).

---

Les regs High-8 peuvent être renommés séparément du reste du registre et nécessitent une fusion des uops.

• accès en écriture seule à ah avec mov ah, r8 ou {[20] } renommez AH, sans dépendance à l'ancienne valeur. Ce sont deux instructions qui n'auraient normalement pas besoin D'un uop ALU (pour la version 32 bits).
• un RMW de AH (comme inc ah) le salit.

• setcc ah cela dépend de l'ancien ah, mais le salit toujours. Je pense que mov ah, imm8 est le même, mais n'a pas testé autant de cas de coin.

  (inexpliqué: une boucle impliquant setcc ah peut parfois s'exécuter à partir du LSD, voir la boucle rcr à la fin de ce post. Peut-être que tant que ah est propre à la fin de la boucle, il peut utiliser le LSD?).

  Si ah est sale, setcc ah se confond avec le renommé ah, plutôt que de forcer une fusion dans rax. par exemple %rep 4 (inc al / test ebx,ebx / setcc ah / inc al / inc ah) ne génère aucune UOPs de fusion et ne s'exécute qu'à environ 8.7 c (latence de 8 inc al ralentie par les conflits de ressources des uops pour ah. Aussi le inc ah / setcc ah chaîne dep).

  Je pense que ce qui se passe ici est que setcc r8 est toujours implémenté en lecture-modification-écriture. Intel a probablement décidé qu'il cela ne valait pas la peine d'avoir un uop en écriture seule setcc pour optimiser le cas setcc ah, car il est très rare que le code généré par le compilateur soit setcc ah. (Mais voir le lien godbolt dans la question: clang4. 0 avec -m32 le fera.)

• La lecture de AX, EAX ou RAX déclenche une fusion uop (qui prend en charge le problème frontal / renommer la bande passante). Probablement le RAT (table D'Allocation de Registre) suit l'état high-8-dirty pour l'architecture R [ABCD]X, et même après une écriture à AH se retire, les données AH sont stocké dans un registre physique séparé de RAX. Même avec 256 NOPs entre l'écriture AH et la lecture EAX, il y a une UOP de fusion supplémentaire. (ROB size = 224 sur SKL, donc cela garantit que le mov ah, 123 a été retiré). Détecté avec les compteurs uops_issued / executed perf, qui montrent clairement la différence.

• Lire-modifier-écrire de AL (par exemple inc al) fusionne gratuitement, dans le cadre de L'uop ALU. (Testé uniquement avec quelques simples uop, comme add/inc, pas div r8 ou mul r8). Encore une fois, pas de fusion uop est déclenché même si AH est sale.

• Ecrire uniquement dans EAX / RAX (comme lea eax, [rsi + rcx] ou xor eax,eax) efface L'état AH-dirty (pas de fusion uop).

• Écriture seule à AX (mov ax, 1) déclenche une fusion de AH en premier. Je suppose qu'au lieu de spécial-casing cela, il fonctionne comme n'importe quel autre RMW de AX/RAX. (TODO: test mov ax, bx, bien que cela ne devrait pas être spécial car il n'est pas renommé.)
• xor ah,ah a une latence 1c, n'est pas Dep-breaking, et a toujours besoin d'une exécution port.
• la lecture et / ou l'écriture de AL ne force pas une fusion, donc AH peut rester sale (et être utilisé indépendamment dans une chaîne dep séparée). (par exemple add ah, cl / add al, dl peut fonctionner à 1 par horloge (goulot d'étranglement sur l'ajout de latence).

---

Rendre AH sale empêche une boucle de s'exécuter à partir du LSD (le tampon de boucle), même s'il n'y a pas de UOPs fusionnant. Le LSD est lorsque le processeur recycle uops dans la file d'attente qui alimente l'étape de problème/renommer. (Appelé le IDQ).

Insérer des uops de fusion est un peu comme insérer des UOPs de synchronisation de pile pour le moteur de pile. Le manuel d'optimisation d'Intel indique que le LSD de SnB ne peut pas exécuter de boucles avec des correspondances push/pop, ce qui est logique, mais cela implique qu'il peut exécuter des boucles avec équilibré push/pop. Ce n'est pas ce que je vois sur SKL: même équilibré push/pop empêche l'exécution du LSD (par exemple push rax / pop rdx / times 6 imul rax, rdx. (Il peut y avoir une réelle différence entre le LSD de la BNS et le HSW / SKL: SnB peut simplement "verrouiller" les uops dans L'IDQ au lieu de les répéter plusieurs fois, donc une boucle 5-uop prend 2 cycles à émettre au lieu de 1.25.) Quoi qu'il en soit, il semble que HSW/SKL ne puisse pas utiliser le LSD lorsqu'un registre high-8 est sale ou lorsqu'il contient des uops de stack-engine.

Ce comportement peut être lié à un un erratum dans la touche programmable:

SKL150: les boucles courtes qui utilisent des registres AH / BH / CH / DH peuvent provoquer un système imprévisible Comportement

Problème: dans des conditions micro-architecturales complexes, des boucles courtes de moins de 64 instructions qui utilisent des registres AH, BH, CH ou DH ainsi que leurs registres plus larges correspondants (par exemple RAX, EAX ou AX pour AH) peuvent provoquer un comportement imprévisible du système. Cela ne peut se produire que lorsque les deux processeurs logiques sur le même processeur physique sont actifs.

Cela peut également être lié à la déclaration du manuel d'optimisation D'Intel selon laquelle SnB doit au moins problème / renommer un AH-merge uop dans un cycle par lui-même. C'est une différence étrange pour le front-end.

Mon Journal du noyau Linux dit microcode: sig=0x506e3, pf=0x2, revision=0x84. Le paquet intel-ucode d'Arch Linux fournit simplement la mise à jour, vous devez éditer les fichiers de configuration pour les charger. Donc mon test Skylake était sur un i7-6700k avec la révision du microcode 0x84, qui n'inclut pas le correctif pour SKL150. Il correspond au comportement Haswell dans tous les cas que j'ai testés, IIRC. (par exemple Haswell et mon SKL peut exécuter le setne ah / add ah,ah / rcr ebx,1 / mov eax,ebx boucle du LSD). J'ai HT activé (ce qui est une condition préalable pour que SKL150 se manifeste), mais je testais sur un système principalement inactif, donc mon thread avait le noyau pour lui-même.

Avec microcode mis à jour, le LSD est complètement désactivé pour tout tout le temps, pas seulement lorsque les registres partiels sont actifs. lsd.uops est toujours exactement zéro, y compris pour les programmes réels pas de boucles synthétiques. Bugs matériels (plutôt que microcode bugs) souvent nécessite la désactivation d'une fonctionnalité entière à corriger. C'est pourquoi SKL-avx512 (SKX) est signalé pour ne pas avoir de tampon de bouclage. Heureusement, ce n'est pas un problème de performance: le débit UOP-cache accru de SKL sur Broadwell peut presque toujours suivre le problème/renommer.

---

Extra ah/BH/CH/DH latence:

• Lire AH quand ce n'est pas sale (renommé séparément) ajoute un cycle de latence supplémentaire pour les deux opérandes. par exemple, add bl, ah a une latence de 2c de l'entrée BL à sortie BL, de sorte qu'il peut ajouter de la latence au chemin critique même si RAX et AH ne font pas partie de celui-ci. (J'ai déjà vu ce genre de latence supplémentaire pour l'autre opérande, avec une latence vectorielle sur Skylake, où un retard int/float "pollue" un registre pour toujours. TODO: écrire ça.)

Cela signifie déballer les octets avec movzx ecx, al / movzx edx, ah a une latence supplémentaire vs. movzx/shr eax,8/movzx, mais encore un meilleur débit.

• Lire AH quand il est sale ne pas ajouter aucune latence. (add ah,ah ou add ah,dh/add dh,ah ont 1C latence par ajouter). Je n'ai pas fait beaucoup de tests pour confirmer cela dans de nombreux cas.

  Hypothèse: une valeur high8 sale est stockée dans le fond d'un registre physique . La lecture d'un high8 propre nécessite un décalage pour extraire les bits [15: 8], mais la lecture d'un high8 sale peut simplement prendre des bits [7: 0] d'un registre physique comme une lecture normale de registre 8 bits.

Une latence supplémentaire ne signifie pas un débit réduit. Ce le programme peut fonctionner à 1 iter par 2 horloges, même si toutes les instructions add ont une latence 2c (à partir de la lecture DH, qui n'est pas modifiée.)

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

---

Quelques corps de boucle de test intéressants :

%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

La version setcc (avec le %if 1) a une latence de boucle 20C, et s'exécute à partir du LSD même si elle a setcc ah et 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% )

Inexpliqué: il court à partir du LSD, même si elle rend AH sale. (Du moins je pense il n'. TODO: essayez d'ajouter des instructions qui font quelque chose avec eax avant que mov eax,ebx ne l'efface.)

Mais avec mov ah, bl, Il s'exécute en 5.0 c par itération (imul goulot d'étranglement de débit) sur HSW/SKL. (Le magasin/rechargement commenté fonctionne aussi, mais SKL a un transfert de magasin plus rapide que HSW, et c'est 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% )

Notez qu'il ne fonctionne plus à partir du LSD.