Kompilieren von GNU/Linux mit -O3-Optimierung

-O3 hat mehrere Nachteile:

1. Erstens produziert es oft langsameren Code als -O2 oder -Os . Manchmal wird aufgrund des Abrollens der Schleife längerer Code erzeugt, der aufgrund der schlechteren Cache-Leistung des Codes tatsächlich langsamer sein kann.
2. Wie gesagt, es produziert manchmal falschen Code. Dies kann entweder auf einen Fehler bei der Optimierung oder auf einen Fehler im Code (wie das Ignorieren von striktem Aliasing) zurückzuführen sein. Da Kernel-Code manchmal "intelligent" ist und manchmal sein muss, würde ich sagen, dass ein Kernel-Entwickler einen Fehler gemacht hat. Ich hatte verschiedene seltsame Probleme, wie das Abstürzen von Userspace-Dienstprogrammen, als ich den Kernel mit gcc 4.5 kompilierte, der zu diesem Zeitpunkt stabil war. Aufgrund verschiedener Fehler verwende ich immer noch gcc 4.4 für den Kernel und einige ausgewählte Userspace-Dienstprogramme. Dasselbe kann für -O3 gelten .
3. Ich glaube nicht, dass es viel Nutzen für den Linux-Kernel bietet. Der Kernel führt keine schweren Berechnungen durch und an manchen Stellen ist er mit Assembler optimiert. -O3 Flag wird nicht Ändern Sie die Kosten für den Kontextwechsel oder die E/A-Geschwindigkeit. Ich glaube nicht, dass sich so etwas wie <0,1 % Beschleunigung der Gesamtleistung lohnt.

Es wird in Gentoo verwendet und mir ist nichts Ungewöhnliches aufgefallen.

Beachten Sie, dass große Teile der Toolchain (insbesondere Glibc) nicht kompiliert werden, wenn Sie die Optimierungsstufen ändern. Das Build-System ist so eingerichtet, dass es Ihre -O-Einstellungen für diese Abschnitte auf den meisten vernünftigen Distributionen ignoriert.

Einfach ausgedrückt hängen bestimmte grundlegende Bibliotheks- und Betriebssystemfunktionen davon ab, dass der Code tatsächlich tut, was er sagt, und nicht davon, was in vielen Fällen schneller wäre. Insbesondere -fgcse-after-reload (aktiviert durch -O3) kann seltsame Probleme verursachen.