Dlaczego llvm i gcc używają różnych prologów funkcji na x86 64?

Question

Trywialny funkcja Mam kompilacji z gcc i brzękiem:

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 

I

$ 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 

Różnica Jestem zainteresowany jest gcc używa sub rsp, 8/add rsp, 8 dla funkcji prolog i clang używa push rax/pop rdx.

Dlaczego kompilatory używają różnych prologów funkcji? Który wariant jest lepszy? push i pop z pewnością koduje krótsze instrukcje, ale czy są one szybsze czy wolniejsze niż add i sub?

Powodem, dla którego chodzi przede wszystkim o manipulowanie stertami, wydaje się, że abi wymaga, aby rsp miał 16 bajtów wyrównanych dla procedur bez liści. Nie mogłem znaleźć żadnych flag kompilatora, które je usunęły.

Sądząc z odpowiedzi, wygląda na to, że pop jest lepszy. push rax + pop rdx = 1 + 1 = 2 vs. sub rsp, 8 + add rsp, 8 = 4 + 4 = 8. Tak więc pierwsza para oszczędza 6 bajtów bez żadnych kosztów.

Answer 1

Intel, sub/add uruchomi silnik stosu wstawić dodatkowy uop, aby zsynchronizować %rsp dla części wykonawczej wykonanej poza kolejnością. (Patrz Agner Fog's microarch doc konkretnie pg 91, o silniku stosu. AFAIK, to nadal działa tak samo na Haswell jak na Pentium M, w miarę gdy musi wstawić dodatkowych UOPs.

push/pop zajmie mniej skondensowane -domain ups, a więc prawdopodobnie będzie bardziej wydajne, nawet jeśli używają portów store/load.Należy między nimi:

Tak więc, push/pop przynajmniej nie będzie wolniejsze, ale pobiera mniej instrukcji Lepsza gęstość I-cache jest dobra

BTW, myślę, że punktem pary insynuacji jest utrzymanie wyrównanego stosu 16B ter call przesuwa adres zwrotny 8B. Jest to jeden przypadek, w którym ABI kończy się wymaganiem instrukcji pół-bezużytecznych. Bardziej skomplikowane funkcje, które wymagają trochę miejsca na stos, aby rozlać locals, a następnie załadować je ponownie po wywołaniu funkcji, zwykle będą wymagały zarezerwowania miejsca.

SystemV (Linux) amd64 ABI gwarantuje, że przy wprowadzaniu funkcji, (%rsp + 8), gdzie argumenty na stosie będą, jeśli takie istnieją, będą wyrównane 16B. (http://x86-64.org/documentation/abi.pdf). Musisz to zorganizować w przypadku każdej funkcji, którą wywołujesz, lub jest to twoja wina, jeśli ulegają uszkodzeniu dzięki użyciu wyrównanego obciążenia SSE. Lub w inny sposób rozbić się na założeniu, w jaki sposób można użyć AND do maskowania adresu lub czegoś.

Answer 2

Zgodnie z eksperymentami, które zrobiłem na moim komputerze, push/pop mają tę samą prędkość, co add/sub. Sądzę, że tak powinno być w przypadku wszystkich mordern komputerów.

Zresztą różnica (jeśli w ogóle) jest naprawdę mikro-scopic, więc proponuję założyć, że są one równoważne ...