DE3586374T2

DE3586374T2 - Verfahren zur elimination globaler gemeinsamer unterexpressionen und zur kodeverschiebung in einem optimierenden kompilierer.

Info

Publication number: DE3586374T2
Application number: DE8585108879T
Authority: DE
Inventors: Marc Alan Auslander; John Cocke; Peter Willy Markstein
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1984-08-13
Filing date: 1985-07-16
Publication date: 1993-03-04
Anticipated expiration: 2005-07-17
Also published as: JPS6149242A; EP0171631A2; DE3586374D1; US4656583A; EP0171631A3; EP0171631B1; JPH0695311B2

Description

Diese Erfindung eignet sich in besonderem Maße für einen Kompilierer, in dem zur Qualitätsverbesserung des Kodes Optimierungsalgorhythmen verwendet werden. Diese Erfindung verkürzt insbesondere die Dauer zur Durchführung der Optimierungen, die als Elimination gemeinsamer Unterausdrücke und Kodeverschiebung bekannt sind. Darüberhinaus dient diese Erfindung zur Effektivitätssteigerung der oben angeführten Optimierungen.
Zwar eignet sich die Erfindung zur Optimierung von Kompilierern aller Computertypen, doch hat sie besondere Bedeutung für Computer mit reduzierten Befehlssätzen, für die der durch Kompilierer erstellte Kode häufig umfangreicher ist als der für Computer mit komplexen Befehlssätzen erstellte Kode, da jeder Befehl eines Computers mit reduzierten Befehlssätzen einfacher ist und weniger Funktionen ausführen kann. Eine größere Nachfrage besteht nach einer Optimierung eines Kodes, der für einen Computer mit reduziertem Befehlssatz erstellt wurde.
Schon seit der erste Kompilierer hergestellt wurde, ist die Qualität der von Kompilierern erzeugten Kodes eine wichtige Frage. Eines der wesentlichen Ziele des IBM FORTRAN I Kompilierers, des ersten Kompilierers auf dem Markt, war die Erstellung eines Objektkodes im Bereich der wissenschaftlichen Berechnungen, die in ihrer Kodequalität vergleichbar waren mit den von Programmierern in Assemblersprache "von Hand" erstellten Kodes.
Heute stehen komplexere Sprachen für alle Bereiche zur Verfügung, in denen Computer anwendbar sind. Selbst die ursprüngliche Sprache FORTRAN wurde weiterentwickelt, um sie auf viele unterschiedliche Programmieranforderungen anwendbar zu machen. Nach wie vor jedoch ist die Qualität der vom Kompilierer erstellten Kodes von großer Bedeutung, besonders dann, wenn der resultierende Kode in einer Produktionsumgebung verwendet werden soll. Ein durch einen erfahrenen Programmierer in Assemblersprache erstellter Kode ist noch immer der Maßstab, an dem ein von einem Kompilierer erstellter Kode gemessen wird. Seit den fünfziger Jahren wurden zahlreiche Optimierungstechniken entwickelt und verfeinert, um die Qualität der durch Kompilierer erstellten Kodes zu verbessern. Viele dieser Optimierungen waren vom Prinzip her bereits bekannt und wurden von der Arbeitsgruppe, die den ersten FORTRAN Kompilierer entwickelte, in einer bestimmten Art und Weise verwendet.
Optimierungsmethoden, die häufig zur Optimierung von Kompilierern verwendet werden, sind beispielsweise die Unterdrückung gemeinsamer Unterausdrücke, die Kodeverschiebung von Bereichen mit hoher Ausführungsfrequenz in Bereiche mit niedriger Ausführungsfrequenz, die Elimination toter Kodes, die Stärkereduktion (Ersetzen einer langsamen Operation durch eine gleichwertige schnelle Operation) und die konstante Propagation. Beschreibungen dieser Optimierungen sind in folgenden Werken enthalten:
J. T. Schwartz, On Programming - An Interim Report on the SETL Language. Installment II: The SETL Language and Examples of Its Use, Courant Institute of Math Sciences, NYU, 1983, Seiten 293-310.
E. Morel und C. Renvoise - Global Optimization by Suppression of Partial Redundancies, CACM, Vol. 22, No. 2, Seiten 96-103, 1979.
A. Aho, J. Ullman, Principles of Compiler Design, Addison- Wesley, 1977.
Die Elimination globaler gemeinsamer Unterausdrücke und die Kodeverschiebung gehören zu den wichtigsten Optimierungsmethoden. Messungen haben ergeben, daß diese Optimierungen sich günstiger auf die Kodequalität auswirken als alle anderen Optimierungsmethoden. Viele Veröffentlichungen zu diesem Thema enthalten Diskussionen darüber, wie diese Optimierungen zustande kommen; die beiden ersten der oben angeführten Quellenverweise enthalten ausgezeichnete Beschreibungen darüber, wie sich bestimmen läßt, an welcher Stelle in einem Programm die Kopie des Kodes einzufügen ist, damit der ursprüngliche Kode überflüssig wird und eliminiert werden kann. Diese Artikel liefern außerdem eine Beschreibung darüber, wie sich feststellen läßt, an welcher Stelle überflüssige Kodes existieren. Die Methoden sind dabei abhängig vom Flußgraph des Programms und von der Kenntnis einiger Eigenschaften, die sich durch einzelne aufeinanderfolgende Untersuchungen von Basisblocks bestimmen lassen. Diese Eigenschaften sind:
DEX (nach unten exponierte Ausdrücke). Der Satz an Berechnungen, der, wenn er am Ende eines Basisblocks ausgeführt wird, zum selben Ergebnis führt wie wenn er an "Ort und Stelle" ausgeführt wird.
UEX (nach oben exponierte Ausdrücke). Der Satz an Berechnungen, der, wenn er am Anfang eines Basisblocks ausgeführt wird, zum selben Ergebnis führt wie wenn er an "Ort und Stelle" ausgeführt wird.
THRU Der Satz an Berechnungen, der, wenn er am Anfang oder am Ende eines Basisblocks ausgeführt wird, zu denselben Ergebnissen führt.
Die oben angegebenen Quellenverweise liefern eine Beschreibung, wie eine Elimination globaler gemeinsamer Unterausdrücke und eine Kodeverschiebung unter der Voraussetzung, daß die oben angeführten Sätze für jeden Basisblock bekannt sind, durchgeführt wird. Insbesondere wird in diesen Referenzquellen beschrieben, wie der am Ende mancher Basisblöcke einzufügende Berechnungssatz zu berechnen ist, um den Effekt der Kodeverschiebung auf der Grundlage der Sätze DEX, UEX und THRU zu erzielen. Experten auf diesem Gebiet sind mit diesen Berechnungen vertraut.
Wird jedoch bei der Berechnung von UEX, DEX und THRU nicht acht gegeben, so können die Algorhythmen für das Commoning und für die Kodeverschiebung möglicherweise nur die erste einer Sequenz zusammenhängender Berechnungen gemeinsam zugreifbar machen und/oder verschieben. Als Beispiel wird das Kodefragment aus Tabelle I betrachtet. TABELLE I OP: INST. BEDEUTUNG 1 L R100, A Inhalt aus A holen, in Register 100 setzen. 2 L R101, B Inhalt aus B holen, in Register 101 setzen. 3 R102, R100, Register 102 auf die Summe der Inhalte aus R101 addieren R100 und R101 setzen. 4 ST R102, C Inhalte aus C auf die Inhalte aus R102 setzen.
Es ist nicht einfach, bei einem Basisblock, der aus dem Kode in Tabelle I besteht, die Berechnung von R102 (Op. 3) in UEX zu setzen, da R100 und R101 möglicherweise beim Eingeben des Basisblocks nicht dieselben Werte aufweisen wie beim Auftauchen einer Addieranweisung. Wenn also Tabelle I der Kode in einer inneren Schleife ist, in der A und B unverändert bleiben, so gehören nur R100 (Op. 1) und R101 (Op. 2) in UEX (dies ist der Instrumentalsatz zur Bestimmung der Kodeverschiebung).
Nach dem Commoning der Kodeverschiebung bleibt die Berechnung von R102 (Op. 3) innerhalb der Schleife, und eine andere Anwendung des Algorhythmus wäre erforderlich, um die Berechnung von R102 zu verschieben.

BESCHREIBUNG NACH DEM BEKANNTEN STAND DER TECHNIK

Das US Patent 4,309,756 beschreibt eine Methode zur Auswertung gewisser logischer Berechnungen. Die beschriebenen Konzepte haben einen sehr kleinen Anwendungsbereich und sind in bezug auf ein im Jahr 1982 erteiltes Patent unzeitgemäß. Die Berechnungen werden nicht unterschiedlich bezeichnet, so daß möglicherweise redundante Berechnungen denselben Namen tragen.
Das britische Patent 1,413,938 befaßt sich mit Verfahren zur Überprüfung der Kompiliererausgabe auf Korrektheit. Es könnte zur Überprüfung von durch Optimierungskompilierer erzeugten Kodes auf Korrektheit dienen. Das Patent enthält jedoch keinen Hinweis darauf, wie der Optimierungskompilierer die Kodes im allgemeinen erzeugt oder wie die Optimierungen erzielt werden.
Das US Patent 4,277,826 sieht die Verwendung des Hashing-Verfahrens vor, um einen Übersetzungsmechanismus für virtuelle Adressen aufrechtzuerhalten. In der vorliegenden Erfindung wurde das Hashing-Verfahren verwendet, um schnell auf Berechnungen zugreifen zu können, auf die man im Kompilierungsablauf getroffen ist. Das Hashing-Verfahren ist bei der Anwendung unserer Erfindung jedoch nur ein nebensächliches Detail.
Die vorliegende Erfindung wird in den beigefügten Patentansprüchen definiert.
In der vorliegenden Erfindung wird die Ableitung einer "Basis" für Berechnungen vorgestellt, und es wird veranschaulicht, wie durch das Ausdrücken aller Berechnungen in "Basiselementen" eine schnellere Durchführung einer Elimination globaler gemeinsamer Unterausdrücke und einer Kodeverschiebung möglich ist.
Die beigefügte Anwendung EP-A-0171592 mit dem Titel "Eine innerhalb eines Optimierungskompilierers durchführbare Methode" besagt, daß unter Anwendung gewisser Strategien zur Kodeerzeugung die Auswahl einer "Basis" während des Ablaufs der Zwischenkodeerzeugung möglich ist. Zur Bestimmung einer Basis ist es nicht notwendig, solange zu warten, bis die Kodeerzeugung abgeschlossen ist. In solchen Fällen können alle Berechnungen während der Zwischenkodeerzeugung in "Basistermen" ausgedrückt werden. Der Kompilierer PL/1L, der beschrieben wird in Cocke, J. und Markstein, P., Measurement of Program Improvement Algorith, Proc. IFIP Cong. '80, Tokyo, Japan, 6-9. Okt. 1980, Melbourne, Australien, 14-17. Okt., 1980, Seiten 221-228, verwendet eine Kodeerzeugungsstrategie und erzeugt dabei Informationen, anhand derer die "Basis" während der Kodeerzeugung in einer Zwischensprache bestimmt werden kann. In diesem Artikel wird jedoch die Erzeugung oder Verwendung einer "Basis" weder beschrieben noch vorgeschlagen.
Bei dem hier verwendeten Begriff Zwischensprache handelt es sich um eine vom Kompilierer verwendete Zwischensprache, die das zu übersetzende Programm darstellt. Die Zwischensprache liegt normalerweise auf einer Ebene unterhalb der Quellensprache und oberhalb der Zielsprache. Optimierende Kompilierer wandeln die Zwischensprachenprogramme in äquivalente, aber bessere, Zwischensprachenprogramme um. Es ist davon auszugehen, daß diese Kompilierungsphase bekannt ist; sie wird daher nicht als eine neue Kompilierungsart angesehen. Sie wird hier nur erläutert, um die vorliegende Erfindung vollständig zu beschreiben. Dieser Ablauf wird in Block 1 von Fig. 2 durchgeführt.
Ein wesentliches Ziel dieser Erfindung besteht darin, einen optimierenden Kompilierer mit einem Modul anzubieten, der es ermöglicht, mehrere zusammenhängende Berechnungen gemeinsam zugreifbar zu machen oder zu verschieben und zwar mit einem einzigen Durchlauf eines Commoning- oder Kodeverschiebungsalgorithmus.
Ein weiteres Ziel dieser Erfindung ist es, das Konzept einer "Basisberechnung" für ein Programm zu verwenden. Alle Berechnungen im Programm können in Basiselementen ausgedrückt werden.
Ein weiteres Ziel dieser Erfindung ist es, zu beschreiben, wie die "Basis" eines Programms dazu verwendet werden kann, den Satz der nach oben exponierten Ausdrücke zu berechnen; dies ist zur Durchführung der globalen Commoning- und Kodeverschiebungsalgorhythmen erforderlich.
Der Satz der nach oben exponierten Ausdrücke wird unter Verwendung einer "Basis" berechnet und zwar so, daß mehrere zusammenhängende Berechnungen mit einem einzigen Durchlauf eines Commoning- oder Kodeverschiebungsalgorithmus gemeinsam zugreifbar gemacht oder verschoben werden können.
Ein weiteres Ziel dieser Erfindung ist es, zu zeigen, wie die Basis eines Programms zur Berechnung des Satzes der nach unten exponierten Ausdrücke verwendet werden kann; dies ist zur Durchführung der globalen Commoning- und Kodeverschiebungsalgorhythmen erforderlich. Der Satz der nach unten exponierten Ausdrücke wird unter Verwendung einer "Basis" berechnet und zwar so, daß mehrere zusammenhängende Berechnungen mit einem einzigen Durchlauf eines Commoning- oder Kodeverschiebungsalgorithmus gemeinsam zugreifbar gemacht oder verschoben werden können.
Ein weiteres Ziel dieser Erfindung ist es, zu zeigen, wie die Basis eines Programms dazu verwendet werden kann, um den Satz der unbeeinflußten Berechnungen zu berechnen; dies ist zur Durchführung der globalen Commoning- und Kodeverschiebungsalgorhythmen erforderlich. Der Satz der unbeeinflußten Berechnungen wird unter Verwendung der Basis berechnet und zwar so, daß mehrere zusammenhängende Berechnungen mit einem einzigen Durchlauf eines Commoning- oder Kodeverschiebungsalgorithmus gemeinsam zugreifbar gemacht oder verschoben werden können.
Ein weiteres Ziel dieser Erfindung ist es, zu zeigen, wie die "Vernichtungssätze" berechnet werden, die für jede Basiseinheit die Nichtbasis-Berechnungen sind, die abhängig sind vom Wert der Basiseinheit. Der Satz der nach oben exponierten Ausdrücke, der Satz der nach unten exponierten Ausdrücke und unbeeinflußte Ausdrücke können am einfachsten in Termen der Vernichtungssätze berechnet werden.
Ein weiteres Ziel dieser Erfindung ist es, zu zeigen, wie die "Vernichtungssätze" dazu verwendet werden, um den Satz der verfügbaren Berechnungen zu propagieren, während die Berechnungen in einem Basisblock auf redundante Kodes hin untersucht werden, um diese zu entfernen.
Die Erlangung dieser Ziele durch die Erfindung wird gemäß der Beschreibung in den beiliegenden Ansprüchen beschrieben.

BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein allgemeines funktionales Flußdiagramm eines optimierenden Kompilierers, in dem die vorliegende Erfindung besondere Anwendung findet.
Fig. 2 ist ein allgemeines Flußdiagramm des hier beschriebenen Kompilierermoduls zur Durchführung des gewünschten Commoning- Verfahrens und der gewünschten Kodeverschiebung.
Fig. 3 ist ein allgemeines Flußdiagramm des Algorithmus für den globalen gemeinsamen Unterausdruck und für die Kodeverschiebung, der in einem optimierenden Kompilierer verwendet wird und in dem die vorliegende Erfindung Anwendung findet.

BESCHREIBUNG DER ERFINDUNG

Die vorliegende Erfindung bietet einen Mechanismus an, mit dem in größeren Sätzen UEX, DEX und/oder THRU erkannt werden können; auf diese Weise können größere Kodemengen mit einer einzigen Anwendung des Algorithmus dem Commoning-Verfahren unterzogen oder verschoben werden.
Es folgt eine Definition mehrerer zur Beschreibung der vorliegenden Erfindung verwendeter Begriffe.
BASISBLOCK - Ein Befehlssatz, auf den nur von außerhalb des Satzes über den ersten Befehl zugegriffen werden kann. Jeder Befehl im Basisblock, mit Ausnahme des letzten, hat genau einen Nachfolgebefehl; dieser Nachfolgebefehl befindet sich im Basisblock.
ZWISCHENSPRACHE - Sie wird vom Kompilierer zur Darstellung des zu übersetzenden Programms verwendet. Die Zwischensprache liegt normalerweise auf einer Ebene unterhalb der Quellensprache und oberhalb der Zielsprache. Optimierende Kompilierer wandeln die Zwischensprachenprogramme in äquivalente, aber bessere, Zwischensprachenprogramme um.
BASIS - Die Basis für jeden Basisblock umfaßt Einheiten, die als Operanden verwendet werden, die zuvor nicht innerhalb dieses Basisblocks definiert wurden. Die Gesamtheit solcher Einheiten aus allen Basisblocks wird als "Basis" für das Programm bezeichnet.
NICHTBASIS - Eine Nichtbasiseinheit hingegen ist ein Operand, der vor der Verwendung in diesem Basisblock definiert wurde.
VERNICHTUNGSSATZ - Für jedes Mitglied der Basis wird der Satz an Nichtbasiseinheiten, die von diesem Basismitglied abhängig sind, als Vernichtungssatz des Basiselements bezeichnet. Hierbei ist zu beachten, daß wenn der Wert des Basiselements geändert wird (durch Neuberechnung), alle Mitglieder des dazugehörigen Vernichtungssatzes verschiedene Werte erhalten würden, wenn danach eine Neuberechnung erfolgt.
Zur Fortsetzung der vorliegenden Beschreibung dienen die folgenden Elemente als Berechnungsgrundlage:
1. Alle Benutzervariablen und alle Deskriptoren von Benutzervariablen.
2. Zeiger zur Durchführung von Zeitstapeln und Heaps, in denen Datenobjekte zugeordnet sind.
3. Zeiger zum Objektkode.
4. Verschiedene vom Kompilierer erzeugte vorübergehende Variablen, die den Wert eines Ausdrucks dann annehmen, wenn der Ausdruck berechnet wird. Solche vorübergehenden Variablen ändern ihre Werte auch dann nicht, wenn Operanden, die zur Berechnung der vorübergehenden Variablen verwendet wurden, ihren Wert zu einem späteren Zeitpunkt ändern.
Beispiel: Bei der Übersetzung von do i = a zu b zu c wird in vielen Sprachen das Inkrement c der Induktionsvariablen zu dem Zeitpunkt fixiert, wenn die Schleife eingegeben wird. Auch wenn sich c innerhalb der Schleife ändert, macht es die Semantik solcher Sprachen erforderlich, daß das Inkrement der Wert ist, den c hatte, als die Schleife eingegeben wurde. Dieser ursprüngliche Wert von c wird in einer separaten vorübergehenden Variablen beibehalten.
Auf diese Weise können Basiselemente bestimmt werden, sobald sie auftauchen, entweder weil eine Benutzervariable verwendet wurde oder weil eine Erklärung einer Benutzervariablen aufgetaucht ist oder weil die Benutzervariable zur Zeit der Ausführung einen Deskriptor erfordert oder weil Verweise auf Heaps oder Stapel erfolgen, die zur Durchlauf-Zeit-Umgebung gehören, oder der Kompilierer muß eine separate vorübergehende Variable erzeugen oder der Kompilierer muß auf den Objektkode verweisen (z. B. ein Verzweigungsbefehl).
Die Abbildungen, die die Flußdiagramme der vorliegenden Erfindung (beispielsweise Fig. 3) enthalten, bedürfen meistens keiner näheren Erläuterung. Fig. 1 ist ein sehr allgemeines Flußdiagramm eines Kompilierers, wie er auf diesem Gebiet sehr bekannt ist. Die Blöcke 1, 2, 4 und 5 sind sehr klar dargestellt und bekannt. Block 3 mit dem Titel Kodeoptimierung ist die Phase der Kompiliereraktivität, auf die sich die vorliegende Erfindung bezieht.
Fig. 2 ist ein Flußdiagramm der Optimierungsphase für einen solchen Optimierungskompilierer. Die in den Blöcken 1, 3 und 4 durchgeführten Operationen sind klar dargestellt und bekannt. Block 2 ist der Bereich des Optimierungskompilierers, auf den sich die vorliegende Erfindung bezieht. Dieser Block wird in Fig. 3 vergrößert dargestellt.
Fig. 3 ist ein Flußdiagramm für die globale Commoning- und Kodeverschiebungsphase des Kompilierers. Wie in dieser Spezifikation bereits an früherer Stelle erwähnt wurde, ist das allgemeine Ziel auf der Kompilierer-Planungsebene bekannt. Die spezielle Art, in der die Operationen durchgeführt werden, wird nachfolgend in funktionalen Termen beschrieben.
Die Blöcke 4, 5, 6 und 7 sind, wie bereits erwähnt wurde, innerhalb des Bereichs der Optimierungskompilierer bekannt. Die Operationen werden bezüglich ihrer Funktionen in der nachfolgenden allgemeinen Beschreibung der Gesamtoperation der Phase 'Elimination globaler gemeinsamer Unterausdrücke und Kodeverschiebung' eines typischen Optimierungskompilierers unter Verwendung der vorliegenden Erfindung erläutert.
Spezielle Unterprogramme zur Durchführung dieser Operationen werden in den Anhängen I und III-VI aufgeführt und dienen als Referenz. Die Anhänge I und II enthalten die Unterprogramme, die die in den Blöcken 1, 2 und 3 von Fig. 3 beschriebenen Operationen ausführen; diese Operationen beinhalten die eigentliche Erfindung.
Die Methode erfordert eine Vorgehensweise in folgenden Schritten, die der Übersichtlichkeit halber im wesentlichen in Form von Tabellen dargestellt werden:
1. Jeder Basisblock ist auf Einheiten zu untersuchen, die als Operanden verwendet werden, ohne daß sie zuvor innerhalb dieses Basisblocks definiert wurden. Die Gesamtheit aller solcher Einheiten aus allen Basisblocks wird als 'Basis' für das Programm bezeichnet. Für das Kodefragment aus TABELLE 1 sind A und B Bestandteile dieser Basis. Entsprechend ist eine Nichtbasiseinheit eine Einheit, die zuvor definiert wurde.
Ein Basisblock ist ein Befehlssatz, auf den nur von außerhalb des Satzes mit dem ersten Befehl zugegriffen werden kann. Jeder Befehl im Basisblock, mit Ausnahme des letzten, hat genau einen Nachfolgebefehl; dieser Nachfolgebefehl befindet sich im Basisblock.
2. Für die Berechnung jeder Nichtbasiseinheit ist die Untergruppe der Basiseinheiten zu bestimmen, von der diese abhängig ist. Diese Bestimmung läßt sich durch folgendes wiederkehrendes Verfahren durchführen:
Für den Operandensatz einer Berechnung ist jeder Nichtbasisoperand durch die Basiseinheiten zu ersetzen, von denen dieser Operand abhängig ist.
Auf diese Weise können sämtliche Berechnungen als Funktionen von Basiseinheiten betrachtet werden und nicht als Operanden, die ausdrücklich im Befehl für die Berechnung auftauchen.
3. Als nächster Schritt ist es erforderlich, unter Verwendung der im vorhergehenden Schritt gebildeten Sätze die Gesamtheit an Nichtbasiseinheiten zu finden, die von jeder Basiseinheit abhängig sind. Für jeden Bestandteil der Basis wird der Satz an Nichtbasiseinheiten, der von ihm abhängig ist, als Vernichtungssatz des Basiselements bezeichnet. Hierbei ist zu beachten, daß wenn der Wert des Basiselements geändert wird (durch Neuberechnung), alle Mitglieder des dazugehörigen Vernichtungssatzes verschiedene Werte erhalten würden, wenn danach eine Neuberechnung erfolgt. Demnach wären für das Kodefragment in TABELLE IA und B die Basiseinheiten; die Vernichtungssätze für A und B sind:
kill (A) = (R100, R102)
kill (B) = (R101, R102)
4. Die Sätze DEX, UEX und THRU für jeden Basisblock können nun wie folgt gebildet werden:
a. DEX und UEX auf den leeren Satz initialisieren. THRU auf den Satz aller in Frage kommenden Berechnungen initialisieren. Vor der Untersuchung der Befehle konnte keine Berechnung von Basiseinheiten festgestellt werden; daher wurden keine Berechnungen, die von ihnen abhängen, als vernichtet bestimmt. Im nächsten Schritt wird während der Berechnung von Basiseinheiten der Vernichtungssatz der neu berechneten Basiseinheiten von DEX und THRU entfernt.
b. Befehle im Basisblock in der Reihenfolge der Ausführung untersuchen. Jede auftauchende Nichtbasisberechnung zu DEX hinzufügen. Jede auftauchende Nichtbasisberechnung zu UEX hinzufügen, vorausgesetzt, sie befindet sich ebenfalls in THRU. Jedesmal, wenn eine Basiseinheit berechnet wird, sind von DEX und THRU alle Bestandteile zu entfernen, die ebenfalls Bestandteile des Vernichtungssatzes der Basiseinheit sind.
c. Eine andere Methode zur Berechnung von UEX besteht in der Untersuchung der Befehle in einem Basisblock in umgekehrter Reihenfolge der Ausführung. Jede auftauchende Nichtbasisberechnung zu UEX hinzufügen. Jedesmal, wenn eine Basiseinheit berechnet wird, sind von UEX alle Bestandteile zu entfernen, die ebenfalls Bestandteile des Vernichtungssatzes der Basiseinheit sind. Für den Fachmann bereitet es keine Schwierigkeiten, nachzuweisen, daß die beiden Methoden zur Berechnung von UEX äquivalent sind.
5. Beim Einfügen von Kode in einen Basisblock als Folge der Anwendung von Algorithmen, wie sie im Referenzmaterial gegeben sind, ist sorgfältig auffolgendes zu achten: Hat eine einzufügende Berechnung X einen Operand Y, dessen Berechnung ebenfalls in diesen Basisblock einzufügen ist, so ist die Berechnung dieses Operanden Y als erstes einzufügen. Mit der Technik dieser Erfindung kann eine solche Bedingung nicht auftauchen, da Y vor X in einem Basisblock dazu führen würde, daß X nicht nach oben exponiert wäre. Da der einzufügende Satz an Berechnungen ungeordnet ist, dient diese Beobachtung zur Durchführung einer Ordnung eingefügter Berechnungen, wenn eine Ordnung erforderlich ist.
6. Bei der Verwendung des Satzes verfügbarer Berechnungen (AVAIL), die sich von DEX, UEX und THRU ableiten, ist jeder Befehl eines Basisblocks in der Reihenfolge der Ausführung zu untersuchen. Befindet sich in AVAIL eine Berechnung, so kann diese als redundant angesehen werden. Ist eine Berechnung nicht in AVAIL, dann gilt:
a. Berechnet der Befehl eine Nichtbasiseinheit, so ist die Nichtbasiseinheit zum Satz der verfügbaren Berechnungen AVAIL hinzuzufügen.
b. Berechnet der Befehl eine Basiseinheit, so sind von AVAIL die Bestandteile des Vernichtungssatzes der Basiseinheit zu entfernen, die momentan ebenfalls Bestandteile von AVAIL sind.
Im folgenden Beispiel wird die Verwendung der vorliegenden Erfindung anhand einer vergleichsweise langen Kodeliste veranschaulicht. Im Beispiel sind Vernichtungssätze von Basiseinheiten gekennzeichnet und für die Verwendung in nachfolgenden Operationen zur Bildung von UEX, DEX und THRU zusammengestellt. Das Beispiel zeigt außerdem, wie die resultierenden Listen UEX, DEX und THRU ohne Verwendung der vorliegenden Erfindung ausgesehen hätten.
Nachfolgend ein PL/1 Beispielprogramm zur Darstellung unserer Erfindung:
1 test: proc;
2 dcl i fixed bin;
3 dcl (j, k) fixed bin external;
4 dcl a(10) fixed bin;
5 do i = 1 to 10;
6 a(i) = j + k;
7 end;
8 return;
9 end;
Die Ziffern zu Beginn jeder Zeile von PL/1 dienen lediglich der Kennzeichnung. Nach der Kodeerzeugung hat unser Kompilierer den folgenden Kode erstellt. In der Liste in der Zwischensprache zeigen die Ziffern zu Beginn der Zeile jeweils an, welche Zeile im Quellenkode die Erzeugung der Zeile in der Zwischensprache bewirkt hat. Damit man dem Kode einfacher folgen kann, weisen wir darauf hin, daß die Operation RET die Rückkehr aus dem Unterprogramm markiert. LHA und STHA bedeuten Halbwort Laden vom Speicher beziehungsweise Halbwort Stellen in den Speicher. LR kopiert die Inhalte des rechten Operanden in die Inhalte des linken Operanden (mnemonische Kurzform für Laden Register). BF ist die mnemonische Kurzform für Verzweigung bei Fehler (Branch on False). Sie bewirkt, daß der Steuerungsfluß zu dem im letzten basierten Operanden angegebenen Label geht, wenn ein Bit in dem durch den ersten Operanden spezifizierten Register gleich Null ist. Das zu untersuchende Bit ist durch den zweiten Operanden gegeben. Gemäß dem Beispiel bewirkt der von BF gefolgte Befehl CI, daß die Steuerung zu Label %3 fließt, wenn die Inhalte von R100 nicht größer als 10 sind. Die anderen Operationskodes sind dem Fachmann offensichtlich; in der Zwischensprache ist der ganz links befindliche Operand das Ergebnis der Durchführung der Operation, die angegeben ist auf dem Basisblock 1 Gemäß Seite 9, Schritt 1, der Beschreibung bestimmen wir die Basis folgendermaßen
Gemäß Schritt 2 der Beschreibung stellen wir folgende Abhängigkeiten für jede Nichtbasiseinheit fest:
R100 I, R15
R101 I, R15
R102 I, R15
R106 I, R15
R109 I, R15
R111 R15, R118, /.STATIC
R112 R15, R118, /.STATIC, .J
R113 R15, R118, /.STATIC, .K
R114 R15, R118, /.STATIC, .J, J
R115 R15, R118, /.STATIC, .K, K
R116 R15, R118, /.STATIC, .J, .K, J, K
Die Durchführung von Schritt 3 liefert uns die folgenden Vernichtungssätze für die Basiseinheiten:
Basis Vernichtungssatz
R15 R100, R101, R102, R106, R109, R111, R112, R1l3, R114, R115, R116
R118 R111, R112, R113, R114, R115, R116
I R100, R101, R102, R106, R109
/.STATIC R111, R112, R113, R114, R115, R116
.J R112, R114, R116
J R114, R116
.K R113, R115, R116
K R115, R116
Die Sätze DEX, UEX und THRU werden anschließend durch Schritt 4 für die Basisblöcke bestimmt. Daraus ergibt sich:
Basisblock 1:
dex (1) R98, R100, R111
uex (1) R98
thru (1) R98
Basisblock 2:
dex (2) R100, R102, R111, R112, R113, R114, R115, R116
uex (2) R100, R101, R106, R109, R111, R112, R113, R114,
R115, R116
thru (2) R98, R111, R112, R113, R114, R115, R116
Basisblock 3:
dex (3) leerer Satz
uex (3) leerer Satz
thru (3) R98, R100, R101, R102, R106, R109, R111, R112, R113, R114, R115, R116
Gemäß den in Schritt 5 vorgeschlagenen Algorithmen werden die Sätze AVAIL und THRU und die Hilfssätze GDX, GUX, PAX, CIE und CIX folgendermaßen berechnet:
Basisblock 1
gdx(1) R98, R100, R111
gux(1) R98
pax(1) leerer Satz
cie(1) leerer Satz
cix(1) R100, R111, R112, R113, R114, R115, R116
insert(1) R112, R113, R114, R115, R116
avail(1) leerer Satz
Basisblock 2
gdx(2) R98, R100, R102, R111, R112, R113, R114, R115, R116
gux(2) R100, R101, R106, R109, R111, R112, R113, R114, R115, R116
pax(2) R98, R100, R102, R111, R112, R113, R114, R115, R116
cie(2) R100, R111, R112, R113, R114, R115, R116
cix(2) leerer Satz
insert(2) leerer Satz
avail(2) R100, R111, R112, R113, R114, R115, R116
Basisblock 3
gdx(3) R98, R100, R102, R111, R112, R113, R114, R115, R116
gux(3) leerer Satz
pax(3) R98, R100, R102, R111, R112, R113, R114, R115, R116
cie(3) leerer Satz
cix(3) leerer Satz
insert(3) leerer Satz
avail(3) leerer Satz
Als Ergebnis der Kodeeinfügungen gemäß der Beschreibung in Schritt 5 und der Elimination der redundanten Kodes gemäß der Beschreibung in Schritt 6 erhält man folgendes Programm. (Zeilen mit der Kennzeichnung '9999' sind Kodezeilen, die vom Kodeeinfügungsprogramm herrühren.) Dieses Zwischenkodeprogramm ist mit dem obigen zu vergleichen, um zu sehen, welche Änderungen im Programm vorhanden sind: Basisblock 1 Basisblock 3
Der Vorteil der folgenden Erfindung wird ersichtlich, wenn man sich folgendes vor Augen hält: Wären der Commoning-Algorithmus und der Kodeverschiebungsalgorithmus ohne die Basis und ohne die Vernichtungssätze angewandt worden, so wären DEX, UEX und THRU möglicherweise folgendermaßen bestimmt worden:
Basisblock 1
dex(1) R98, R100, R111
uex(1) R98
thru(1) leerer Satz
Basisblock 2
dex(2) R100, R102, R111, R112, R113, R114, R115, R116
uex(2) R100, R111
thru(2) R98
Basisblock 3
dex(3) 3 leerer Satz
uex(3) leerer Satz
thru(3) R98, R100, R101, R106, R109, R111, R112, R113, R114, R115, R116
Als Konsequenz wären nur die Berechnungsbefehle R100 und R111 für die Kodeverschiebung herangezogen worden. Das Programm sähe folgendermaßen aus: Basisblock 1 Basisblock 2 Basisblock 3
Zu berücksichtigen ist, daß fünf Befehle innerhalb der Schleife belassen wurden. Ohne die vorliegende Erfindung wären für die Erzielung desselben Ergebnisses drei zusätzliche Anwendungen des Commoning-Prozesses und des Kodeverschiebungsprozesses erforderlich; in der vorliegenden Erfindung konnte dasselbe Ergebnis mit einem Verfahren erzielt werden, das nur eine einzige Anwendung des Commoning- und Kodeverschiebungsalgorithmus verwendet.
Es folgt eine kurze mathematische Beschreibung der Verwendung der Listen von UEX, DEX und THRU. Insbesondere wird dabei die Funktion der Listen AVAIL und INSERT und ihre Verwendung bei der Erzeugung der endgültigen Ausgabe bei der in Fig. 3 beschriebenen Prozedur erörtert.
Für jeden Basisblock B ist es erforderlich, die folgenden Berechnungssätze aus UEX, DEX und THRU zu bestimmen:
avail (B) Diejenigen Berechnungen, deren Ergebnisse gültig sind, wenn in den Basisblock B gegangen wird.
insert (B) Diejenigen Berechnungen, die tatsächlich am Ende von Basisblock B eingefügt werden, um andere Berechnungen redundant werden zu lassen. Die Kodeverschiebung wird durch wohlüberlegtes Einfügen und Entfernen von Kode erzielt.
Die an früherer Stelle zitierten Referenzen enthalten eine Beschreibung von Methoden zur Berechnung von AVAIL und INSERT aus UEX, DEX und THRU. Bei der Entscheidung, wann eine Kodeverschiebung durchzuführen ist, spielen mehrere Kriterien eine Rolle. Dem Leser wird empfohlen, alle an früherer Stelle zitierten Referenzen durchzulesen, um mehrere verschiedene Aspekte vor Augen geführt zu bekommen. Um die vorliegende Erfindung in sich geschlossen werden zu lassen, wird für die Berechnung von AVAIL und INSERT die Methode von Morel und Renvoise angewandt. Dem Leser wird dringend empfohlen, deren Schrift zur Rechtfertigung ihrer Methode durchzulesen.
Zur Berechnung von AVAIL und INSERT werden für jeden Basisblock fünf zusätzliche Berechnungssätze eingeführt:
gux (B) Global nach oben exponierte Berechnungen. Wenn diese Berechnungen am Anfang des Basisblock B durchgeführt werden, so wird dasselbe Ergebnis erzielt wie wenn die Berechnung an Ort und Stelle durchgeführt wird (nicht notwendigerweise im Basisblock B).
gdx (B) Global nach unten exponierte Berechnungen. Wenn diese Berechnungen am Ende des Basisblock B durchgeführt werden, so wird dasselbe Ergebnis erzielt wie wenn die Berechnung zuvor durchgeführt wurde, unabhängig von ihrem vorigen Steuerfluß.
pax (B) Teilweise verfügbare Berechnungen. Es existiert mindestens ein Steuerflußpfad, entlang welchem diese Berechnungen durchgeführt wurden und bei denen dasselbe Ergebnis erzielt wurde wie erzielt worden wäre, wenn die Berechnungen am Anfang des Basisblocks B durchgeführt worden wären.
cix (B) Berechnungen, die am Ausgang des Basisblocks B eingefügt werden könnten und deren Einfügung sicherstellen würde, daß derselbe Befehl entlang jedes Steuerflußpfads, der den Basisblock B verläßt, redundant gemacht wird.
cie (B) Berechnungen, die am Eingang des Basisblocks B eingefügt werden könnten und deren Einfügung sicherstellen würde, daß derselbe Befehl entlang jedes Steuerflußpfads, der in den Basisblock B geht, redundant gemacht wird.
Die Gleichungen, die diese Berechnungssätze definieren, sind folgende:
gux(b) = uex(b) U gux(s) bis (b) (1)
(s Vorgänger(b))
gdx(b) = dex(b) U (dex(p) U gdx(p) bis (p)) (2)
p (Vorgänger(b))
pax(b) = U (dex(p) U pax(p) bis (p)) (3)
p Vorgänger(b)
cix(b) = cie(s) (4)
s Vorgänger(b)
gux(b) (uex(b) U cix(b) bis(b))
pax(b) U (bis(b)-uex(b))) (5)
cie(b)= (cix(p) U gdx(p))
p Vorgänger(b)
insert(b) pix(b)-gdx(b)-(pie(b) bis(b)) (6)
avail(b) = pie(b) uex(b) (7)
Eine Methode zur Lösung dieser Gleichungen ist die Initialisierung von gux (b) und pax (b) auf den leeren Satz für alle Basisblöcke b und die Initialisierung von gdx (b) auf den Satz aller Berechnungen für alle Basisblöcke mit Ausnahme des Eingangsbasisblocks, für den gdx (Eingangsbasisblock) auf den leeren Satz initialisiert wird. (Der Eingangsbasisblock stellt den Kode dar, der ausgeführt wird, wenn die Steuerung zuerst in das Programm geht, das kompiliert wird.) Die Gleichungen (1), (2) und (3) werden je durch Neuberechnung von gux (b), gdx (b) bzw. pax (b) gelöst; dies gilt für alle Basisblöcke solange, bis die Neuberechnung die Sätze für keinen der Basisblöcke mehr ändert.
Nach der Berechnung von gux (b), gdx (b) und pax (b) für alle Basisblöcke b lösen wir als nächstes gleichzeitig die Gleichungen (4) und (5). pie (b) und pix (b) auf den Satz aller Ausdrücke mit zwei Ausnahmen initialisieren. pie (Eingangsblock) und pix (Ausgangsblock) werden auf den leeren Satz initialisiert. Dann ist wiederholt sowohl pix (b) als auch pie (b) aus den Gleichungen (4) und (5) für alle Basisblocks b neu zu berechnen, bis die Neuberechnung die Sätze für keinen der Basisblocks mehr ändert.
Schließlich können insert (b) und avail (b) unter Verwendung von uex (b) und thru (b) sowie der Ergebnisse der Berechnungen von gdx (b), pix (b) und pie (b) direkt aus den Gleichungen (6) und (7) berechnet werden.
Die nachfolgende Tabelle bezieht sich auf die Anhänge I bis VI der Blöcke aus Fig. 3. Diese Unterprogramm-Kodefragmente sind im PL/1 Kode geschrieben und mit ausreichenden Erklärungen versehen, um einem geübten Programmierer zu ermöglichen, die vorliegende Erfindung in einem optimierenden Kompilierer entweder in der dargestellten Form zu verwenden oder auf einfache Weise die Unterprogramme in einer anderen Zielsprache, die mit seinem Kompilierer besser kompatibel ist, neu zu schreiben.
Wie an früherer Stelle bereits erwähnt wurde, stellen die in den Anhängen I und II aufgeführten Programme das eigentliche Thema der vorliegenden Erfindung dar, wie dies in den Blöcken 1, 2 und 3 aus Fig. 3 aufgeführt ist; die übrigen Anhänge II bis VI stellen Programme dar, die die in den Blöcken 4 bis 7 aus Fig. 3 spezifizierten Operationen ausführen. ANHANG REFERENZTABELLE Anhang Nr. Block aus Fig. 3 Anhang 1 Anhang 2 Anhang 2, Fortsetzung Anhang 2, Fortsetzung Anhang 2, Fortsetzung Anhang 2, Fortsetzung Anhang 3 Anhang 3, Fortsetzung Anhang 3, Fortsetzung Anhang 3, Fortsetzung Anhang 4 Anhang 4, Fortsetzung Anhang 4, Fortsetzung Anhang 4, Fortsetzung Anhang 4, Fortsetzung Anhang 4, Fortsetzung Anhang 5 Anhang 5, Fortsetzung Anhang 5, Fortsetzung Anhang 5, Fortsetzung Anhang 6 Anhang 6, Fortsetzung Anhang 6, Fortsetzung

Claims

1. Verfahren zum Durchführen einer Elimination globaler gemeinsamer Unterausdrücke und einer Codebewegung innerhalb der Codeoptimierungsphase eines optimierenden Compilers, wobei das Verfahren gemäß einer Repräsentation eines Programms mittels einer Zwischensprache läuft, in dem Basisprogrammblöcke identifiziert wurden, welches die folgenden Schritte umfaßt:

(a) identifizieren von Basiseinheiten in jedem Basisblock zum nachfolgenden Verarbeiten, bei welchem eine Basiseinheit als ein Operand definiert ist, auf den in einem Basisblock Bezug genommen wird, bevor er berechnet wird,

(b) Erstellen einer Liste von Vernichtungssätzen für die Basiseinheiten, wobei ein Vernichtungssatz für eine Basiseinheit jede keine Basiseinheit darstellende Einheit enthält, die von der einen Basis für seinen Wert abhängt.

(c) Berechnen der Sätze UEX, DEX und THRU unter Verwendung der Basiseinheiten und der Vernichtungssatzdaten,

bei welchen UEH (nach oben freie Berechnungen) als der Satz von Berechnungen definiert wird, die, falls an dem Anfang eines Basisblocks ausgeführt dasselbe Ergebnis liefern, wie wenn an der ursprünglichen Stelle in dem Block ausgeführt und durch folgendes berechnet wird:

Initialisieren von UEX für den leeren Satz, Prüfen der Befehle in einem Basisblock in Ausführungsfolge oder verkehrter Ausführungsfolge und Hinzufügen jeder aufgefundenen keine Basiseinheit darstellenden Einheit zu UEH, die sich früher in der Ausführungsfolge nicht in dem Vernichtungssatz für eine Basiseinheit befindet,

bei welchen DEH (nach unten freie Berechnung) als Satz von Berechnungen definiert wird, die, falls an dem Ende eines Basisblockes ausgeführt, dasselbe Ergebnis liefern, wie wenn an der ursprünglichen Stelle in dem Block ausgeführt und durch folgendes berechnet wird: Initialisieren von DEX für den leeren Satz, Prüfen der Befehle in einem Basisblock in Ausführungsfolge, Hinzufügen jeder aufgefundenen keine Basiseinheit darstellenden Einheit zu DEH und Entfernen des Vernichtungssatzes für jede aufgefundenen Basiseinheit aus DEX und

bei welchen THRU als der Satz von Berechnungen definiert wird, die, falls an dem Anfang oder dem Ende eines Basisblocks ausgeführt, dasselbe Ergebnis liefern, wie wenn an der ursprünglichen Stelle in dem Block ausgeführt und durch folgendes berechnet wird: Initialisieren von THRU für den Satz aller Berechnungen von Interesse, Prüfen der Befehle in einem Basisblock in Ausführungsfolge und Entfernen des Vernichtungssatzes für jede aufgefundene Basiseinheit aus THRU,

(d) Berechnen von AVAIL und INSERT aus UEX, DEH und THRU, bei welchen AVAIL als der Satz von Berechnungen definiert wird, deren Ergebnisse gültig sind, wenn der Basisblock eingegeben wird und INSERT als der Satz von Berechnungen definiert wird, die an dem Ende des Basisblocks eingefügt werden, wobei an jenen, durch AVAIL und INSERT angezeigten Stellen geeignete Codeeinfügungen vorgenommen werden und

(e) Entfernen eines redundanten Codes unter Verwendung des AVAIL-Satzes.

2. Verfahren nach Anspruch 1, bei welchem ULX durch folgendes berechnet wird:

während der Berechnung von THRU Hinzufügen jeder aufgefundenen keine Basiseinheit darstellenden Einheit zu UEX, vorausgesetzt, daß sie sich auch in THRU befindet.

3. Verfahren nach Anspruch 1, bei welchem UEX durch folgendes berechnet wird:

Prüfen der Befehle in dem Basisblock in verkehrter Ausführungsfolge,

Hinzufügen jeder aufgefundenen keine Basiseinheit darstellenden Einheit zu UEH und

Entfernen irgendwelcher Elemente aus UEX, die auch Elemente des Vernichtungssatzes einer Basiseinheit sind, wann auch immer eine Basiseinheit berechnet wird.

4. Verfahren nach irgendeinem vorgehenden Anspruch, bei welchem der Schritt(e) ferner folgendes umfaßt:

Prüfen jedes Befehls eines Basisblocks in Ausführungsfolge und Ausscheiden einer Einheit, als redundant, falls sie sich in AVAIL befindet.