Superoptimierer. Manuel Odendahl

Transkript

1 Superoptimierer Manuel Odendahl 2. Juni 2003

2 Inhaltsverzeichnis 1 Einführung 1 2 Beispiel: Berechnen des Vorzeichens einer Integer Zahl 2 3 Implementierung Befehlsdefinition Befehlsfolgengenerierung und Testen Erweiterungen 5 Literatur 6 1 Einführung Bei vielen Projekten, besonders im Bereich der eingebetteten Applikationen, ist handoptimierter Assemblercode immer noch notwendig, da optimierende Compiler oft suboptimalen Maschinencode erzeugen. Assemblerprogrammierung benötigt jedoch eine tiefgreifende Kenntniss der unterliegenden Maschinenarchitektur, und handoptimierter Code lässt sich nur sehr geringfügig auf andere Architekturen portieren. In seinem Artikel Superoptimizer - A Look at the Smallest Program [4] stellt Massalin ein Programm vor, mit dem Code erzeugt werden kann, der qualitativ gleichrangig, wenn nicht besser als handoptimierter Code ist. Den Superoptimierer, den er vorstellt, optimiert eine gegebene Assemblercodesequenz A, in dem er den Suchraum der Assemblerprogramm mit einer Breitensuche durchgeht, und jedes Programm für bestimmte Testwerte mit A vergleicht. Sind die Ergebnisse verschieden, wird das Assemblerprogramm verworfen, sonst ist eine mögliche Optimierung von A gefunden worden. Das Programm von Massalin benutzt dazu die unterliegende Hardware als Emulationsplattform, indem er generierte Programm einfach direkt ausführt. Spätere Ansätze benutzen virtuelle Instruktionen, und können somit auch für unterschiedliche Hardwarearchitekturen Code optimieren. Wegen der überwältigenden Grösse des Suchraums (alle mögliche Zielmaschinenprogramme) werden verschiedene Kompromisse gemacht und Optimierungen eingesetzt. In einem ersten Abschnitt werde ich ein kurzes Beispiel aus dem Artikel von Massalin vorstellen, an dem gezeigt wird, welche Art von Optimierung ein Superoptimierer durchführen kann. Anschliessend werde ich die Implementierung eines Superoptimierers anhand der des Programms Aha! von Henry S. Warren, Jr und einer eigenen Implementierung erläutern. Schliesslich werde ich kurz verschiedene Erweiterungen und mögliche Optimierungen des Verfahrens beschreiben. 1

3 2 Beispiel: Berechnen des Vorzeichens einer Integer Zahl In dem Artikel von Massalin wird als Beispiel die Funktion signum gegeben, die in C folgendermaßen aussieht: int signum(int x) { if (x > 0) return 1; else if (x < 0) return -1; else return 0; } signum wird von den meisten Übersetzern in Befehle übersetzt (Massalin verwendet in seiner Arbeit den Befehlssatz). Handoptimierte Assemblerlösungen sind ungefähr 8 Instruktionen lang, ein guter Programmierer kann daraus 6 Befehle machen. Der Superoptimierer jedoch generiert folgenden Code (x ist in d 0, das Ergebnis wird in d 1 zurückgeliefert): add.l d0, d0 ; addieren von d0 mit sich selbst subx.l d1, d1 ; substrahieren von (d1 + carry flag) von d1 negx.l d0 ; (0 - d0 - carry flag) nach d0 addx.l d1, d1 ; addieren von (d1 + carry flag) auf d1 Die Vorgehensweise hinter diesem Codebeispiel ist wie bei den meisten superoptimierten Programmen recht komplex. Das Programm funktionniert in etwa so: add.l d0, d0 verdopplet den Inhalt von d 0, verlegt aber vor allem das Vorzeichenbit in den Carry Flag. subx.l d1, d1 berechnet d 1 d 1 carry = carry, so dass d 1 = 0, falls d 0 >= 0, und d 1 = 1, falls d 0 < 0. negx.l d0 setzt den Carry Flag gdw. d 0 0. addx.l d1, d1 berechnet d 1 = d 1 + d 1 + carry. Falls d 0 < 0 war, dann ist d 1 = 1 und carry = 1, so dass d 1 = d 1 + d 1 + carry = 1. Falls d 0 = 0 war, dann ist d 1 = 0 und carry = 0, so dass d 1 = d 1 + d 1 + carry = 0. Falls d 0 > 0 war, dann ist d 1 = 0 und carry = 1, so dass d 1 = d 1 + d 1 + carry = 1. Dieses Beispiel zeigt, wie effektiv ein Superoptimierer sein kann. 2

4 3 Implementierung 3.1 Befehlsdefinition Der Superoptimierer von Massalin generierte anhand von Befehlsmasken gültige Maschinenbefehle für den unterliegenden Prozessor. Dabei wurde eine Breitensuche mit maximaler Tiefe durch den Suchraum der gültigen Programme gemacht. Allerdings wurde weder Masken für Speicherzugriffs noch fuer Kontrollflussbefehle benutzt, da sie zu Speicherschutzverletzungen bzw. zu unendlichen Schleifen führen konnten. Die neueren Ansätze von Torbjörn Granlund [1] und Henry S. Warren Jr. [3] benutzen nicht mehr die unterliegende Hardware zum Testen der Programme, sondern virtuelle Befehle, mit denen beliebige Architekturen emuliert werden können. Ich werde in diesem Abschnitt auf die Vorgehensweise von Warren Jr. eingehen, die in dem Benutzerhandbuch zu seinem Superoptimierer Aha! [3] beschrieben wird, und insbesondere auch auf einer eigenen Implementierung in LISP, die auf Aha! basiert. Bei Aha! können nur 3-Register-Befehl Architekturen emuliert werden, da der eigentliche Registersatz der Zielarchitektur nicht modelliert wird. Es werden nur virtuelle Register benutzt, die entweder die Eingabeparameter beinhalten, oder Ergebnisse von vorigen Befehlen. Es ist also dem Benutzer überlassen, Programme, die auf einer bestimmten Architektur (z.b. x86) nicht gültig sind, zu eliminieren. Allerdings sind die meisten modernen RISC Architekturen 3-Register-Befehl Architekturen. Bei Aha! werden Befehle durch folgende Parameter beschrieben: 1. Eine Funktion, die die Instruktion emuliert 2. Die Anzahl an Operanden (Eingangsparameter) 3. Die Kategorie der einzelnen Operanden Jeder Befehlsparameter gehört einer der folgenden Kategorien an: Zahlenwert (z.b. 0, 1, -1, usw...). Es können nur bestimmte vorgegebene Zahlenwerte benutzt werden, da das Durchlaufen des kompletten Integerbereichs den Verzweigungsfaktor ins Unermessliche erhöhen würde (> auf einer 32-Bit Architektur). Zahlenwert zum Schieben (meistens 1, 2, 3, 4, usw...). Der Operand wird als Verschiebungsindex benutzt. Register. Bei Aha! werden die Eingabeargumente und die Ergebnisse der einzelnen Befehle als Register benutzt. Bevor der erzeugte Assemblercode eingesetzt werden kann muss der Programmierer die Register an die Zielmaschine wieder anpassen. 3

5 In der LISP Implementierung sind Befehlsdefinition geringfügig flexibler, da beliebige Wertelisten als Operandendefinitionen benutzt werden können (z.b. bei der add Instruktion die literalen Wert 1, 1, 4, 4, siehe Abbildung 1). (make-instruction add ; Name des Befehls ( register (register )) ; Operanden ;; Implementierung des Befehls (multiple-values-bind (res carry) (add-bits 16 r0 r1) (setf (get-flag-value machine carry) (if carry 1 0)))) Abbildung 1: Add Befehl in der LISP Implementierung Anhand dieser Befehldefinitionen werden konkrete Befehle generiert, in dem für die Operanden aus den Beschreibungen konkrete Werte berechnet werden (siehe Abbildung 2 für add). Wenn ein Register als Parameter übergeben werden kann, werden folgende virtuelle Register eingesetzt: 1. Eins der Eingaberegister (Eingabewerte für die zu optimierende Funktion) 2. Eins der Ergebnisse der vorigen Befehle (z.b. Ergebnis des 2. Befehls) Die LISP-Implementierung berechnet zu einer Befehlsdefinition alle möglichen Kombinationen der Operandenwerte, und instanziiert mit ihnen konkrete Instruktionen. Aha! geht dabei ein bisschen feinfühliger vor, indem redundante Instruktionen (z.b. permutierte Operanden bei kommutativen Befehlen) eliminiert werden. (generate-concrete-instructions add ; Add Befehl (list (make-register 0)) ; Liste der benutzbaren Register :result-register (make-register 1)) ; Ergebnisregister => (INS{r1 = ADD r0, r0} INS{r1 = ADD r0, -4} INS{r1 = ADD r0, 4} INS{r1 = ADD r0, -1} INS{r1 = ADD r0, 1}) Abbildung 2: Konkrete Befehl zu dem Add Befehl in der LISP Implementierung 4

6 3.2 Befehlsfolgengenerierung und Testen Zu jeder Befehlsdefinition wird die Menge der gültigen konkreten Befehle generiert, und zu Programmmen der Länge l kombiniert. Dabei wird der komplette Raum der gültigen Programme der Länge l eingespannt. Jedes dieser Programme wird dann in einem Breitensuchverfahren ausgewertet, und die Ergebnisse mit den Ergebnissen der zu optimierenden Funktion verglichen. Stimmen diese überein, ist möglicherweise ein optimales Programm gefunden worden. Um die Suche zu beschleunigen, wird jedes Programm nur für ein paar Eingabewerte ausgewertet. Somit ist es möglich, auch falsche Programme zu finden. Es wird dem Benutzer überlassen, die Korrektheit des gefundenen Programms genauer zu überprüfen. Lässt man die LISP Implementierung optimierte Assemblerprogramme für das Programm in 2 suchen, kommt es zu folgenden Ergebnissen: (search-program test ; Testimplementierung eines Prozessors 4 ; Gesuchte Länge ;; Zu optimierende Funktion # (lambda (x) (cond ((> x 0) 1) ((< x 0) -1) (t 0))) ;; Testwerte ((1) (-1) (0) (2) (-2) (10000) (20000) ( ) ( ))) => (INS{r2 = ADD rs0, rs0} INS{r3 = SUB rs0, rs0} INS{r4 = NEG rs0} INS{r5 = ADD r3, r3}) (INS{r2 = ADD rs0, rs0} INS{r3 = SUB r2, r2} INS{r4 = NEG rs0} INS{r5 = ADD r3, r3}) (INS{r2 = NEG rs0} INS{r3 = ADD rs0, rs0} INS{r4 = ADD rs0, rs0} INS{r5 = SUB r3, r4}) (INS{r2 = NEG rs0} INS{r3 = ADD rs0, rs0} INS{r4 = SUB r3, rs0} INS{r5 = SUB r4, rs0}) (INS{r2 = NEG rs0} INS{r3 = SUB rs0, r2} INS{r4 = ADD r2, r3} INS{r5 = SUB rs0, r4})... Wie man sieht wurde hier dieselbe Lösung wie mit dem Optimierer von Massalin gefunden. Die restlichen Programme sind auf einer 2-Register Architektur (wie z.b. der Prozessor) nicht implementierbar und können ignoriert werden. Sie sind meistens nur Umordnungen der gültigen Lösung. 5

7 4 Erweiterungen Rajeev Joshi, Greg Nelson und Keith Randall [2] entwarfen Denali, ein Superoptimierer, der basierend auf einen automatischen Beweiser korrekten Code generiert, allerdings wurde das System noch nicht vollständig implementiert. Torbjörn Granlund und Richard Kenner benutzten einen Superoptimierer, um für den GCC optimierten Code für die RS6000 Architektur zu generieren. Desweiteren wär es möglich, die Breitensuche des Superoptimierers zu massiv zu parallelisieren. 5 Zusammenfassung Ein Superoptimierer ist ein Programm, der den kompletten Raum der gültigen Programme durchläuft, um ein möglichst kurzes Programm zu finden, dass dieselben Ergebnisse wie eine Referenzimplementierung des zu optimierenden Programms liefert. Damit können aufwendige Handoptimierungen maschinell durchgeführt werden. Allerdings ist der Aufwand des Verfahrens sehr hoch, so dass kaum optimierte Programme mit mehr als 8 Befehlen gefunden werden können. Genauso können keine komplexe Programme mit Sprungbefehlen gefunden werden. 6

8 Literatur [1] Torbjörn Granlund and Richard Kenner. Eliminating branches using a superoptimizer and the gnu c compiler [2] Rajeev Joshi, Greg Nelson, and Keith Randall. Denali: A goal-directed superoptimizer [3] Henry S. Warren Jr. Aha! manual [4] Henry Massalin. Superoptimizer - a look at the smallest program