Una función trivial que estoy compilando con gcc y clang:
void test() { printf("hm"); printf("hum"); } $ gcc test.c -fomit-frame-pointer -masm=intel -O3 -S sub rsp, 8 .cfi_def_cfa_offset 16 mov esi, OFFSET FLAT:.LC0 mov edi, 1 xor eax, eax call __printf_chk mov esi, OFFSET FLAT:.LC1 mov edi, 1 xor eax, eax add rsp, 8 .cfi_def_cfa_offset 8 jmp __printf_chkY
$ clang test.c -mllvm --x86-asm-syntax=intel -fomit-frame-pointer -O3 -S # BB#0: push rax .Ltmp1: .cfi_def_cfa_offset 16 mov edi, .L.str xor eax, eax call printf mov edi, .L.str1 xor eax, eax pop rdx jmp printf # TAILCALL La diferencia que me interesa es que gcc usa sub rsp, 8 / add rsp, 8 para la función prolog y clang usa push rax / pop rdx .
¿Por qué los compiladores usan prólogos de funciones diferentes? ¿Qué variante es mejor? push y pop ciertamente codifican instrucciones más cortas, pero ¿son más rápidas o más lentas que add y sub ?
La razón por la que la pila se manipula en primer lugar parece ser que el abi requiere que rsp esté alineado en 16 bytes para los procedimientos que no son hojas. No he podido encontrar ningún indicador del compilador que los elimine.
A juzgar por sus respuestas, parece que push & pop es mejor. push rax + pop rdx = 1 + 1 = 2 contra sub rsp, 8 + add rsp, 8 = 4 + 4 = 8 . Entonces, el primer par ahorra 6 bytes sin costo alguno.
En Intel, sub / add activará el motor de pila para insertar una uop adicional para sincronizar %rsp para la parte de ejecución fuera de orden de la canalización. (Consulte el documento microarch de Agner Fog , específicamente la página 91, sobre el motor de pila. AFAIK, todavía funciona igual en Haswell que en Pentium M, en cuanto a cuándo necesita insertar uops adicionales.
El push / pop requerirá menos uops de dominio fusionado y, por lo tanto, probablemente sea más eficiente a pesar de que usan los puertos de almacenamiento/carga. Vienen entre pares call/ret.
Entonces, push / pop al menos no será más lento, pero requiere menos bytes de instrucción. Una mejor densidad de caché I es buena.
Por cierto, creo que el objetivo del par de insns es mantener la pila alineada con 16B después de que la call empuje la dirección de retorno 8B. Este es un caso en el que la ABI termina requiriendo instrucciones semi-inútiles. Las funciones más complejas que necesitan algo de espacio de pila para derramar locales, y luego volver a cargarlas después de las llamadas a funciones, normalmente sub $something, %rsp para reservar espacio.
SystemV (Linux) amd64 ABI garantiza que en la entrada de la función, (%rsp + 8) , donde estarán los argumentos en la pila, si los hay, estarán alineados 16B. ( http://x86-64.org/documentation/abi.pdf ). Debe hacer arreglos para que ese sea el caso para cualquier función que llame, o es su culpa si fallan en el uso de una carga alineada con SSE. O, de lo contrario, se bloquea al hacer suposiciones sobre cómo pueden usar AND para enmascarar una dirección o algo así.
De acuerdo con los experimentos que hice en mi máquina, push/pop tienen la misma velocidad que add/sub . Supongo que debería ser el caso de todas las computadoras modernas.
De todos modos, la diferencia (si la hay) es realmente microscópica, por lo que le sugiero que asuma con seguridad que son equivalentes...