Wann sollte ich den Rahmenzeiger weglassen?

Gibt es eine wesentliche Optimierung, wenn der Rahmenzeiger weggelassen wird? Wenn ich das beim Lesen richtig verstanden habe Dies Seite, -fomit-frame-pointer wird verwendet, wenn wir das Speichern, Einrichten und Wiederherstellen von Frame-Zeigern vermeiden möchten.

Wird das nur bei jedem Funktionsaufruf gemacht und wenn ja, lohnt es sich wirklich, ein paar Anweisungen für jede Funktion zu vermeiden? Ist das nicht trivial für eine Optimierung. Was sind die tatsächlichen Auswirkungen der Verwendung dieser Option, abgesehen von den Debugging-Einschränkungen?

Ich habe den folgenden C-Code mit und ohne diese Option kompiliert

int main(void)
{
        int i;

        i = myf(1, 2);
}

int myf(int a, int b)
{
        return a + b;
}

,

# gcc -S -fomit-frame-pointer code.c -o withoutfp.s
# gcc -S code.c -o withfp.s

.

diff -u Das Auslesen der beiden Dateien ergab den folgenden Assembler-Code:

--- withfp.s    2009-12-22 00:03:59.000000000 +0000
+++ withoutfp.s 2009-12-22 00:04:17.000000000 +0000
@@ -7,17 +7,14 @@
        leal    4(%esp), %ecx
        andl    $-16, %esp
        pushl   -4(%ecx)
-       pushl   %ebp
-       movl    %esp, %ebp
        pushl   %ecx
-       subl    $36, %esp
+       subl    $24, %esp
        movl    $2, 4(%esp)
        movl    $1, (%esp)
        call    myf
-       movl    %eax, -8(%ebp)
-       addl    $36, %esp
+       movl    %eax, 20(%esp)
+       addl    $24, %esp
        popl    %ecx
-       popl    %ebp
        leal    -4(%ecx), %esp
        ret
        .size   main, .-main
@@ -25,11 +22,8 @@
 .globl myf
        .type   myf, @function
 myf:
-       pushl   %ebp
-       movl    %esp, %ebp
-       movl    12(%ebp), %eax
-       addl    8(%ebp), %eax
-       popl    %ebp
+       movl    8(%esp), %eax
+       addl    4(%esp), %eax
        ret
        .size   myf, .-myf
        .ident  "GCC: (GNU) 4.2.1 20070719 

Könnte bitte jemand Licht ins Dunkel bringen Schlüssel Punkte des obigen Codes, wo -fomit-frame-pointer tatsächlich den Unterschied gemacht hat?

Bearbeiten: objdump‘s Ausgabe ersetzt durch gcc -S‘s

-fomit-frame-pointer ermöglicht die Verfügbarkeit eines zusätzlichen Registers für allgemeine Zwecke. Ich würde annehmen, dass dies wirklich nur eine große Sache auf 32-Bit-x86 ist, das ein bisschen nach Registern hungert.*

Man würde erwarten, dass EBP nicht mehr bei jedem Funktionsaufruf gespeichert und angepasst wird, und wahrscheinlich eine zusätzliche Verwendung von EBP in normalem Code und weniger Stapeloperationen, wenn EBP als Allzweckregister verwendet wird.

Ihr Code ist viel zu einfach, um einen Nutzen aus dieser Art der Optimierung zu ziehen – Sie verwenden nicht genügend Register. Außerdem haben Sie den Optimierer nicht aktiviert, was möglicherweise erforderlich ist, um einige dieser Effekte zu sehen.

* ISA-Register, keine Mikroarchitekturregister.

Der einzige Nachteil des Weglassens ist, dass das Debuggen viel schwieriger ist.

Der große Vorteil ist, dass es ein zusätzliches Allzweckregister gibt, das einen großen Unterschied in der Leistung machen kann. Offensichtlich wird dieses zusätzliche Register nur bei Bedarf verwendet (in Ihrer sehr einfachen Funktion wahrscheinlich nicht); in einigen Funktionen macht es mehr Unterschied als in anderen.

Sie können häufig aussagekräftigeren Assemblercode von GCC erhalten, indem Sie die verwenden -S Argument zur Ausgabe der Assembly:

$ gcc code.c -S -o withfp.s
$ gcc code.c -S -o withoutfp.s -fomit-frame-pointer
$ diff -u withfp.s withoutfp.s

GCC kümmert sich nicht um die Adresse, sodass wir die tatsächlich generierten Anweisungen direkt vergleichen können. Für Ihre Blattfunktion ergibt dies:

 myf:
-       pushl   %ebp
-       movl    %esp, %ebp
-       movl    12(%ebp), %eax
-       addl    8(%ebp), %eax
-       popl    %ebp
+       movl    8(%esp), %eax
+       addl    4(%esp), %eax
    ret

GCC generiert keinen Code, um den Frame-Zeiger auf den Stack zu schieben, und dies ändert die relative Adresse der Argumente, die an die Funktion auf dem Stack übergeben werden.

Profilieren Sie Ihr Programm, um festzustellen, ob es einen signifikanten Unterschied gibt.

Erstellen Sie als Nächstes ein Profil Ihres Entwicklungsprozesses. Ist das Debuggen einfacher oder schwieriger? Verbringen Sie mehr Zeit mit der Entwicklung oder weniger?

Optimierungen ohne Profiling sind Zeit- und Geldverschwendung.