Warum führt 'Link Time Optimization' zu größeren Binärdateien?

Haben Sie die Binärdatei nach dem Verknüpfen mit -flto entfernt (sie sollte sowohl zur Kompilierung als auch zur Verbindungszeit bereitgestellt werden)?

Übrigens, beachten Sie das die gleiche Optimierung Flags ( -flto -Os ) sollten beide zur Kompilierungszeit und zur Zeit des Links übergeben werden. Wenn Sie bei der Linking-Phase vergessen haben, wie Sie es getan haben , LTO wird nicht funktionieren! (Wenn Sie make verwenden, möchten Sie CC=gcc -flto -Os nicht CFLAGS= -flto -Os ).

^{Sie haben -Os bei link Zeit vergessen, im Zusatz von -flto ; Die Übergabe von -flto zur Verbindungszeit ohne Optimierungen ist falsch: Die LTO-Phase würde höchstens "de-optimieren"}

Ich weiß, dass -flto viele Abschnitte in den ELF-Objektdateien und ausführbaren Dateien hinzufügt (diese Abschnitte enthalten die Serialisierung von internen GCC-Repräsentationen wie Gimple ....). Ich denke (aber habe nicht überprüft), dass die Verknüpfung sie nicht entfernt.

Der Hauptpunkt von LTO ist auch inline über mehrere Kompilierungseinheiten und dies wird voraussichtlich den Code wachsen lassen. Vielleicht sollten Sie LTO in Ihrem speziellen Fall nicht verwenden.

Die meisten redundanten Funktionen sind bereits entfernt (durch den Linker "GC" in Sektionen), auch ohne LTO.

Übrigens könnten Sie objdump oder readelf verwenden, um das herauszufinden.

Wichtig für LTO ist die Unterstützung des funktionierenden Linker-Plugins. Nur damit kann GCC aggressive unerreichbare Code-Entfernung und andere Optimierungen vornehmen. Stellen Sie sicher, dass Sie einen Plugin-Linker aktiviert haben (versuchen Sie es einfach, wenn die LTO-Verknüpfung mit dem -fuse-linker-plugin funktioniert)