Sortie de compilateur complexe pour un constructeur simple

Comme d'autres l'ont commenté, le compilateur n'a aucune obligation d'optimiser votre code lorsque vous ne le lui demandez pas, mais une grande partie de l'inefficacité provient de:

• les paramètres de débordement du compilateur passés dans les registres à une zone d'attente de la pile lors de l'entrée dans la fonction (puis en utilisant les copies sur la pile par la suite)
• le fait qu'Intel ne dispose d'aucune instruction MOV de mémoire à mémoire

Ces deux facteurs se combinent pour vous donner le code que vous voyez dans le démontage (bien que clang fasse clairement un meilleur travail que gcc ici).

Le compilateur renverse ces registres dans la pile pour faciliter le débogage - parce qu'ils sont sur la pile, les paramètres passés dans la fonction restent disponibles tout au long de la fonction et cela peut être très utile lors du débogage. En outre, vous pouvez jouer des astuces comme la correction de nouvelles valeurs pour les paramètres susmentionnés à un point d'arrêt avant de continuer l'exécution, lorsque vous réalisez ce que leurs valeurs devraient réellement être et que vous voulez continuer votre session de débogage.

Je ne sais pas pourquoi les deux compilateurs mettent à zéro a_ et b_ avant de les leur attribuer lors de votre désassemblage. Je ne vois pas ça chez Godbolt .

Que se passe-t-il et pourquoi?

Si vous n'activez pas les optimisations, le compilateur stocke toutes les variables de la pile , et le compilateur renvoie toutes les valeurs de la pile . La raison pour laquelle il le fait est qu'il permet aux débogueurs de suivre plus facilement ce qui se passe dans le programme: ils peuvent observer la pile du programme.

De plus, chaque fonction doit mettre à jour le pointeur de pile lorsque la fonction est entrée, et réinitialiser le pointeur de pile lorsque la fonction est quittée. C'est aussi pour le bénéfice du débogueur: le débogueur peut toujours dire exactement quand vous entrez une fonction ou quittez une fonction.

Code avec -O0:

X::X(unsigned long, unsigned long):
    mov     rax, rdi
    mov     rdx, rsi
    ret

Code avec -O1 :

X::X(unsigned long, unsigned long):
    mov     rax, rdi
    mov     rdx, rsi
    ret

Est-ce que c'est important?

En quelque sorte. Le code sans optimisations est beaucoup plus lent, en particulier parce que le compilateur doit faire des choses comme ça. Mais il n'y a pratiquement aucune raison ne pas d'activer l'optimisation.

Comment déboguer du code optimisé

gcc et clang ont tous deux l'option -Og : cette option active toutes les optimisations qui ne interfère avec le débogage. Si la version de débogage du code s'exécute lentement, essayez de la compiler avec -Og .

Code avec -Og:

X::X(unsigned long, unsigned long):
    push    rbp        // Push the frame pointer to the stack
    mov     rbp, rsp   // Copy the frame pointer to the rsb register
    // Create the object (on the stack)
    mov     QWORD PTR [rbp-8], rdi  
    mov     QWORD PTR [rbp-16], rsi
    mov     QWORD PTR [rbp-24], rdx
    mov     rax, QWORD PTR [rbp-8]
    mov     rdx, QWORD PTR [rbp-16]
    mov     QWORD PTR [rax], rdx
    mov     rax, QWORD PTR [rbp-8]
    mov     rdx, QWORD PTR [rbp-24]
    mov     QWORD PTR [rax+8], rdx
    nop     // IDEK why it does this
    // Pop the frame pointer
    pop     rbp
    ret

Resources

Plus d'informations sur -Og et d'autres options pour faciliter le débogage du code: https: // gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

Plus d'informations sur les options d'optimisation et d'optimisation: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options p >