Quand les compilateurs vont-ils optimiser le code d'assemblage en source C/C++?

Question

La plupart des compilateurs n'optimisent pas le code d'assemblage en ligne (VS2015, gcc), cela nous permet d'écrire de nouvelles instructions qu'il ne supporte pas.

Mais quand un compilateur C/C++ doit-il mettre en œuvre l'optimisation en ligne de l'assemblage en ligne?

Answer 1

En général, les compilateurs n'optimiseront pas le contenu de votre assemblage en ligne. Autrement dit, ils ne supprimeront pas ou ne changeront pas d'instructions dans votre bloc d'assemblage. En particulier, gcc passe simplement à travers le corps de votre assembly inline inchangé à l'assembleur sous-jacent (gas dans ce cas).

Cependant, les bons compilateurs peuvent optimiser autour de votre assembly en ligne, et dans certains cas, peuvent même omettre le code d'exécution en ligne! Gcc, par exemple, peut le faire s'il détermine que les sorties déclarées de l'assemblage sont mortes. Il peut également lever un bloc d'assemblage d'une boucle ou combiner plusieurs appels en un seul. Donc, il ne gâche jamais les instructions à l'intérieur du bloc, mais il est tout à fait raisonnable de changer le nombre de fois qu'un bloc serait exécuté. Bien sûr, ce comportement peut également être désactivé si le bloc a un autre effet secondaire important.

Les docs gcc sur la syntaxe ASM étendue ont quelques good examples de toutes ces choses.

Answer 2

Jamais. Cela irait à l'encontre du but de l'assemblage en ligne, qui est d'obtenir exactement ce que vous demandez.

Si vous souhaitez utiliser la pleine puissance de l'instruction du CPU cible définie d'une manière que le compilateur peut comprendre et optimiser, vous devez utiliser les fonctions intrinsèques , pas asm en ligne.

par exemple. au lieu de asm inline pour popcnt, utilisez int count = __builtin_popcount(x); (dans GNU C compilé avec -mpopcnt). Inline-asm est aussi spécifique au compilateur, donc si quelque chose d'intrinsèque est plus portable, surtout si vous utilisez les intrinsèques x86 d'Intel qui sont supportés par tous les principaux compilateurs qui peuvent cibler x86. Utilisez #include <x86intrin.h> et vous pouvez utiliser int _popcnt32 (int a) pour obtenir de façon fiable l'instruction popcnt x86. Voir , et d'autres liens dans le wiki tag x86.

---

int count(){ 
    int total = 0; 
    for(int i=0 ; i<4 ; ++i) 
    total += popc(i); 
    return total; 
} 

Compilé avec #define popc _popcnt32 par gcc6.3:

mov  eax, 4 
    ret 

clang 3.9 with an inline-asm definition of popc, on the Godbolt compiler explorer:

xor  eax, eax 
    popcnt eax, eax 
    mov  ecx, 1 
    popcnt ecx, ecx 
    add  ecx, eax 
    mov  edx, 2 
    popcnt edx, edx 
    add  edx, ecx 
    mov  eax, 3 
    popcnt eax, eax 
    add  eax, edx 
    ret 

Ceci est un exemple classique de asm en ligne défaisant la propagation constante, et pourquoi vous shouldn Ne l'utilisez pas pour la performance si vous pouvez l'éviter: https://gcc.gnu.org/wiki/DontUseInlineAsm.

---

C'était la définition inline-asm j'ai utilisé pour ce test:

int popc_asm(int x) { 
    // force use of the same register because popcnt has a false dependency on its output, on Intel hardware 
    // this is just a toy example, though, and also demonstrates how non-optimal constraints can lead to worse code 
    asm("popcnt %0,%0" : "+r"(x)); 
    return x; 
} 

Si vous ne saviez pas que popcnt has a false dependency on its output register on Intel hardware, c'est une autre raison, vous devez laisser au compilateur chaque fois que possible.

---

En utilisant des instructions spéciales que le compilateur ne connaît pas est un cas d'utilisation pour asm en ligne, mais si le compilateur ne connaît pas, il ne peut certainement pas l'optimiser. Avant que les compilateurs ne réussissent à optimiser les intrinsèques (par exemple pour les instructions SIMD), l'intégration en ligne pour ce genre de chose était plus courante. Mais nous en sommes à de nombreuses années au-delà, et les compilateurs sont généralement bons avec les intrinsèques, même pour les architectures non-x86 comme ARM.