Perché llvm e gcc usano prologi di funzioni differenti su x86 64?

Question

Una funzione banale sto compilazione con gcc e 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_chk 

E

$ 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 differenza che mi interessa è che gcc usa sub rsp, 8/add rsp, 8 per la funzione prolog e clang utilizza push rax/pop rdx.

Perché i compilatori utilizzano diversi prologhi di funzione? Quale variante è migliore? push e pop codificano sicuramente per istruzioni più brevi ma sono più veloci o più lenti di add e sub?

Il motivo per cui la pila di puntini sembra essere il fatto che l'abi richiede che rsp sia 16 byte allineati per le procedure non foglia. Non sono stato in grado di trovare alcun flag del compilatore che li rimuove.

A giudicare dalle vostre risposte, sembra che il push del pop & sia migliore. push rax + pop rdx = 1 + 1 = 2 vs. sub rsp, 8 + add rsp, 8 = 4 + 4 = 8. Quindi la prima coppia risparmia 6 byte senza spese.

Answer 1

su Intel, sub/add attiverà il motore di stack per inserire un extra uop per sincronizzare %rsp per la parte di esecuzione fuori servizio della pipeline. (Vedere Agner Fog's microarch doc, specificamente pg 91, sul motore di stack. AFAIK, funziona ancora lo stesso su Haswell come il Pentium M, per quanto quando è necessario inserire UOP extra.

Il push/pop avrà meno fusa -domain uops, e quindi probabilmente sono più efficienti anche se usano le porte store/load.Vengono tra le coppie call/ret.

Quindi, push/pop almeno non sarà più lento, ma richiede meno istruzioni byte Migliore densità della I-cache è buona

BTW, penso che il punto della coppia di insns sia quello di mantenere lo stack allineato 16B af ter call inserisce l'indirizzo di ritorno 8B. Questo è un caso in cui l'ABI finisce per richiedere istruzioni semi-inutili. Funzioni più complesse che richiedono dello spazio di stack per rovesciare i locali e quindi ricaricarle dopo le chiamate di funzione, in genere sono sub $something, %rsp per riservare spazio.

SystemV (Linux) amd64 ABI garantisce che all'ingresso della funzione, (%rsp + 8), dove saranno presenti gli argomenti nello stack, se ce ne sono, sarà allineato a 16B. (http://x86-64.org/documentation/abi.pdf). Devi fare in modo che ciò avvenga per qualsiasi funzione che chiami, o è colpa tua se si segfault dall'uso di un carico allineato SSE. In alternativa, arresta il sistema per fare ipotesi su come utilizzare AND per mascherare un indirizzo o qualcosa del genere.

Answer 2

In base agli esperimenti effettuati sulla mia macchina, push/pop hanno la stessa velocità di add/sub. Immagino che dovrebbe essere il caso per tutti i computer mordern.

In ogni caso, la differenza (se presente) è davvero micro-scopica, quindi vi consiglio di tranquillamente supporre che essi sono equivalenti ...