DE3751306T2

DE3751306T2 - Re-Assoziationsverfahren zur Kodeoptimierung.

Info

Publication number: DE3751306T2
Application number: DE3751306T
Authority: DE
Inventors: John Cocke; Peter Willy Markstein
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1986-10-31
Filing date: 1987-10-27
Publication date: 1996-01-25
Anticipated expiration: 2007-10-28
Also published as: US4802091A; EP0273130A2; JPS63121930A; DE3751306D1; EP0273130A3; EP0273130B1

Description

Bereich der Erfindung

Die vorliegende Erfindung findet eine besonders nützliche Anwendung in einem Compiler, in dem Optimisierungsalgorithmen benutzt werden, um die Qualität des erzeugten Codes zu verbessern. Insbesondere ist sie nützlich beim Verbessern des Codes, der erforderlich ist zur Adressierung gespeicherter Objekte. Sprachen wie FORTRAN, PASCAL, C, PL/1, ADA usw. die sich mit Anordnungen von Objekten befassen, können unter Benutzung der Erfindung zu ausgezeichneten Maschinenprogrammcodes umgeformt werden.
Die vorliegende Erfindung ist nützlich beim Optimieren von Compilern für alle Rechnertypen, sie hat jedoch eine besondere Bedeutung für Rechner mit reduziertem Befehlssatz (RISC), denen der Multplikationsbefehl fehlt, oder für Mikrocomputer, denen entweder ein Multiplikationsbefehl fehlt, oder die einen sehr langsamen Multiplikationsbefehl aufweisen, weil in vielen Fällen diese Erfindung Multiplikationen, die in Adressenberechnungen vorkommen, durch Additionen ersetzen kann.

Hintergrund der Erfindung

Die Qualität von Codes, die durch Compiler erzeugt werden, war schon immer ein Hauptanliegen seit der erste Compiler erzeugt wurde. Eine der Hauptaufgaben des Compilers der IBM in FORTRAN I, des ersten im Handel erhältlichen Compilers, war die Erzeugung eines Maschinenprogrammcodes auf dem Gebiet der wissenschaftlichen Berechnungen, dessen Codequalität vergleichbar war mit der, die durch Programmierer in Assemblersprache erzeugt wurde.
Heutzutage werden höhere Programmiersprachen entwickelt, die auf jedem Gebiet einsetzbar sind, auf dem Rechner verwendet werden. Sogar die ursprüngliche Sprache FORTRAN wurde aufgefrischt, um sie für eine breite Palette von Programmieraufgaben einsetzen zu können. Es ist jedoch noch immer wichtig, daß die Qualität der vom Compiler erzeugten Codes hoch ist, insbesondere wenn der entstehende Code in einer Produktionsumgebung eingesetzt werden soll. Ein von einem erfahrenen Assembler-Programmierer erzeugter Code ist noch immer der Maßstab, an dem Compiler-produzierte Codes gemessen werden.
Seit den Fünfzigerjahren wurde eine große Anzahl Optimierungstechniken entwickelt und verfeinert, um die Qualität der Compiler-erzeugten Codes zu verbessern. Viele dieser Optimierungen waren im Prinzip bekannt und wurden auf irgendeine Weise von dem Team, das den ersten FORTRAN-Compiler erzeugte, benutzt.
Häufig eingesetzte Optimierungen beim Optimieren von Compilern beinhalten die Eliminierung gemeinsamer Unterausdrücke, Verschieben von Codes aus Gebieten großer Ausführungshäufigkeit in Gebiete geringer Ausführungshäufigkeit (Codeverschiebung), Eliminierung toter Codes, Reduktion der Stärke (Ersatz einer langsamen Operation durch eine äquivalente schnelle Operation), konstante Fortpflanzung, und Codeselektion. Beschreibungen solcher Optimierungen sind zu finden in:
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, Seite 293-310.
E. Morel und C. Renvoise, Global Optimization by Suppression of Partial Redundancies, CACM, Bd. 22, Nr. 2, Seite 96-103, 1979.
A. Aho und J. Ullman, Principles of Compiler Design, Addison- Wesley, 1977.
Die in der vorliegenden Anmeldung als 'Reassoziationsverfahren' gekennzeichnete Technik kombiniert viele Transformationen zur Berechnung bestimmter Summen, oder Summen von Produkten, auf wirksamere Weise. Viele dieser Berechnungen entstehen durch Adressieren von abgespeicherten Mengen, und jede Optimierung zur Verbesserung eines solchen Codes muß neben anderen Überlegungen auch die Adressiermodi des Programmablaufrechners in Betracht ziehen.
Einige der hier beschriebenen Effekte wurden sogar schon bei den frühesten Compilern durch andere Mittel erzielt. Insbesondere weist der FORTRAN I Compiler von IBM einen sehr wirksamen Stärkereduktions-Algorithmus auf, um Multiplikationen aus Adressierberechnungen in Schleifenform herauszunehmen. Bei FORTRAN Compilern gehört es zur Tradition, eine effektive Stärkereduktion einzuschließen.
Aber es gibt auch andere Verbesserungen, die nicht auf natürliche Weise aus den Stärkereduktionsroutinen heraus fallen. Diese betreffen die Neuanordnung der Berechnung von Summen, um die Anzahl der gemeinsamen Unterausdrücke zu erhöhen und die Berechnungen so abzustimmen, daß sie zur Adressierungsarchitektur der Programmablaufrechner passen. Auch diese Vorgänge werden mit Reassoziation bezeichnet.
Die Reassoziation zieht diese Punkte auf eine Weise in Betracht, daß die maschinenabhängigen Aspekte leicht parametrisiert werden können. Die Reassoziation erlaubt das Neuanordnen und Vereinfachen der zu adressierenden Berechnungen unter einem abstrakten Gesichtspunkt, der auch dann gültig bleibt, wenn ein Compiler zum Übersetzen einer anderen Sprache oder zur Produktion eines Codes für eine andere Zielmaschine verändert wird.
Wie im Abschnitt 'Stand der Technik' noch dargelegt wird, sind zwar einige der in der sogenannten 'Reassoziationstechnik' benutzten Konzepte bekannt und in der Literatur besprochen, jedoch ist keine spezifische Kombination solcher Konzepte bekannt, die auf einen Optimierungscompiler auf eine Weise angewandt wird, wie sie in der vorliegenden Patentanmeldung dargelegt und beschrieben wird. Es wird angenommen, daß das hier geoffenbarte und beschriebene allgemeine 'Reassoziationsverfahren' in seiner Anwendung auf einen Optimierungscompiler einen signifikant verbesserten Code produziert, wenn es auf eine spezifische Zielarchitektur angewandt wird.

STAND DER TECHNIK

Die nachfolgenden Hinweise bringen allgemeine Hintergrundinformationen über das allgemeine Reassoziationskonzept:
1. Randolph G. Scarborough und Harwood G. Kolsky, "Improved Optimization of FORTRAN Object Programs, IBM J. Res. Develop., Bd. 24, Nr. 6, Seiten 660-676, Nov. 1980.
2. Robert Paige, "Formal Differentiation," Courant Computer Science Report #15, Courant Institute of Mathematical Sciences, New York University, September 1979.
Der Artikel von Scarborough und Kolsky beschreibt eine Anzahl Codetransformationen, die im FORTRAN Compiler von IBM durchgeführt werden, aber der Artikel beschreibt nicht die Mittel, durch die diese Transformationen ausgeführt werden. Alle von Scarborough und Kolsky beschriebenen Codeverbesserungen lassen sich durch die vorliegende Erfindung erzielen, aber auch noch weitere Verbesserungen, die die Autoren nicht beschrieben haben.
Paiges These beschreibt die formelle Methode der Berechnung komplexer Funktionen durch eine formelle Differentiationstechnik. Verfahren wie die von Paige können in allgemeinen Compilern angewandt werden, um einige der Ausdrücke, die die Reassoziation erzeugt, stärkezureduzieren.
Die US-Patente 4,215,416 von Muramatsu, 4,367,535 von Matsuyama und 4,399,517 von Niehaus et al. offenbaren Hardware-Addierer, die 'assoziative' Regeln für Additionen anwenden, und die den 'nächstliegenden' Stand der Technik darstellen, der bei einer Neuheitsrecherche für die vorliegende Erfindung in der klassifizierten Dokumentation des US Patentamts gefunden wurde.
Das hier geoffenbarte Konzept der 'assoziativen' Addition hat wenig Bezug auf das Entfernen von Additionen aus Schleifen und das Entfernen unnötiger Multiplikationen aus einem Objektprogramm, das nach der Lehre der vorliegenden Erfindung compiliert wird.
Die zwei folgenden Patente wurden bei einer allgemeinen Recherche nach Verfahren auf dem Stand der Technik zur Erweiterung der Optimierung von Compilern gefunden.
US-Patent 4,309,756 offenbart ein Verfahren zur Bewertung bestimmter logischer Berechnungen. Die geoffenbarten Konzepte haben nur einen begrenzten Umfang und sind anachronistisch für ein 1982 erteiltes Patent. Es zeigt in erster Linie den allgemeinen Stand der Technik und wirft kein Licht auf das Benennen der Berechnungen, so daß potentiell redundante Berechnungen den gleichen Namen haben.
UK-Patent 1,413,938 betrifft Techniken zum Prüfen eines Compilerausgangs auf Richtigkeit. Es könnte benutzt werden zum Prüfen der Richtigkeit des von einem Optimierungscompiler generierten Codes. Es hat jedoch keinen Bezug darauf, wie der Optimierungscompiler im allgemeinen einen Code generiert oder wie er seine Optimierung durchführt.
AHO et al.: "Compilers, Principles, Techniques and Tools", März 1986, Addision-Wesley, offenbart ein Verfahren zum Compilieren eines Rechnerprogramms, wie im einleitenden Teil des Anspruchs 1 dargelegt wird.

ZUGEHÖRIGE ANWENDUNGEN

Die folgenden Anwendungen beziehen sich alle auf Verfahren zum Einsatz in einem Optimierungscompiler, der einen erweiterten Code für die Zielsystemarchitektur produziert. Sie sind kumulativ zur vorliegenden Erfindung in dem Sinne, daß sie die Compileroptimierung erweitern, sind aber in keiner Weise zur Anwendung der vorliegenden Erfindung erforderlich. Die ersten drei Anwendungen wären alle in erster Linie in der 'Codeoptimierungsphase' des Compilerbetriebs (Block 3 in Fig. 1) anwendbar, ebenso wie auch die vorliegende Erfindung.
EP-A-85 108 435.0 von M.E. Hopkins et al., hat den Titel "A Method of Developing Formal Identities and Program Bases in an Optimizing Compiler." Diese Erfindung lehrt, daß unter bestimmten Codegenerierungsstrategien während des Zwischencode-Generierungsprozesses eine 'Basis' ausgewählt werden kann. Es ist nicht erforderlich, auf den Abschluß der Codegenerierung zu warten, um eine 'Basis' zu bestimmen. In solchen Fällen lassen sich alle Berechnungen in Ausdrücken der 'Basis' unmittelbar während der Zwischencodegenerierung ausdrücken.
EP-A-85 108 879.9 von J. Cocke et al. hat den Titel "A Method for Improving Global Common Subexpression Elimination and Code Motion in an Optimizing Compiler". Diese Erfindung betrifft ein Verfahren oder eine Methode zur Anwendung während der Optimierungsphase eines Optimierungcompilers zur Ausführung der globalen Eliminierung gemeinsamer Unterausdrücke und der Codeverschiebung. Das Verfahren beinhaltet die Bestimmung der Code-'Basis' für das Objektprogramm, was die Prüfung jedes Code-Basisblocks und Bestimmung der 'basis'- Punkte einschließt, von denen jede Berechnung abhängt, wobei 'Basis'-Punkte definiert sind als Operanden, auf die in einem Basisblock Bezug genommen wird, bevor sie berechnet werden. Als nächstes wird der "Kill set" [Abbruchssatz] für jeden 'Basis'-Punkt bestimmt. Anschließend werden UEX, DEX und THRU unter Verwendung der vorher bestimmten 'Basis' und "Kill set" Information für jeden Basisblock bestimmt. AVAIL und INSERT werden aus UEX, DEX und THRU bestimmt, und geeignete Codeeinschübe werden an den Stellen gemacht, die vom vorherigen Schritt angezeigt werden, und schließlich wird der redundante Code unter Verwendung des AVAIL-Satzes entfernt.
EP-A-86 101 873.7 von J. Cocke et al. ist betitelt "Optimization of Range Checking". Diese Erfindung betrifft ein Verfahren, das zum Optimieren von Compilern benutzt wird, und insbesondere ein Merkmal, das als 'Optimization of range checking' [Optimierung der Gültigkeitsbereichsüberprüfung] bekannt ist, welches den Bereichsprüfcode aus Innenschleifen einiger Programme eliminiert, wenn immer das möglich ist. Der geoffenbarte und beanspruchte Algorithmus kann wie folgt synoptisch zusammengefaßt werden: Wenn nach der Schleife auf der Grundlage der Induktionsvariablen eine zusätzliche Schleife existiert, müssen die Tests von den nachfolgenden Blöcken auf einem alternativen Pfad ausgeführt werden. Der Grund dafür ist, daß im nicht-modifizierten Programm der nachfolgende Test den Ausgang aus einer Schleife entlang einem anderen Ausgangspfad bewirkt haben kann, es ist nur erforderlich, zu testen, ob die erzielte Induktionsvariable ihr beabsichtigtes Maximum (oder Minimum, wenn die Induktionsvariable abnimmt) erreicht hat, wenn die Kopie der Tests in den nachfolgenden Blöcken keinen Sprung zum Schleifenausgang bewirkt hätte."
Das in der folgenden gleichzeitig anhängigen Anmeldung beschriebene Verfahren würde hauptsächlich entweder vor oder nach der 'Registerzuweisungsphase' der Compileroperation (Block 4 in Fig. 1) anwendbar sein. Auch in diesem Falle ist die Erfindung kumulativ zu der hier beschriebenen Erfindung.
von M.E. Hopkins et al., hat den Titel "A Method for Generating Short Form Instructions in an Optimizing Compiler". Diese Erfindung betrifft ein Verfahren zur Verbesserung der Qualität der Codes, die von einem Optimierungscompiler oder Assembler für eine Zielmaschine generiert wurden, die Kurz und Langformen für einige ihrer Befehle aufweist, wobei die Kurzformen schneller ablaufen oder weniger Platz beanspruchen. Das Verfahren legt zunächst durch einen Rückwärtsdurchlauf durch das Programm, was einer Lebendigkeitsanalyse ähnlich ist, fest, welche Bits für die Ergebnisse der einzelnen Computerbefehle signifikant sind. Dann werden die auf diese Weise berechneten signifikanten Bits benutzt, um den Codeauswahlprozeß zur Auswahl der am meisten effizienten Befehle zu führen, die das richtige Resultat in allen signifikanten Bitpositionen berechnen.

AUFGABE DER ERFINDUNG

Eine Hauptaufgabe der vorliegenden Erfindung ist das Bereitstellen eines Codeoptimierungsverfahrens zur Anwendung in einem Optimierungscompiler, das die Prinzipien der Reassoziation benutzt, um einen effizienteren Maschinenprogrammcode zu erzeugen.
Eine weitere Aufgabe der Erfindung ist es, ein solches Optimierungsverfahren bereitzustellen, das Multiplikationen durch Additionen in Schleifen (oder eng verbundenen Bereichen) ersetzt, wo immer eine Gelegenheit dazu gefunden wird.
Eine weitere Aufgabe der Erfindung ist das Bereitstellen eines solchen Optimierungsverfahrens, das leicht an die besonderen, in der Architektur des Zielrechners verfügbaren Adressiermodi angepaßt werden kann.
Noch eine weitere Aufgabe der Erfindung ist das Bereitstellen eines solchen Optimierungsverfahrens, in dem das Verfahren individuell auf alle engverbundenen Bereiche des Programms anwendbar ist.
Dementsprechend sieht die Erfindung ein Verfahren zum Compilieren eines Rechnerprogramms vor, wobei das Verfahren eine Optimierungsphase einschließlich der folgenden Schritte aufweist: Durchführung der Kontrollflußanalyse zwecks Identifizierung eng verbundener Bereiche des Programms mit einem einzigen Eingang; Identifizieren, für jeden Programmpunkt und jeden darauf angewandten Operanden, des Satzes (USE) aller Programmpunkte, bei denen das bei P berechnete Objekt als Operand benutzt wird, und des Satzes (DEF) aller Programmpunkte, an denen der Operand berechnet wird und von denen aus der Programmpunkt erreicht werden kann, ohne durch eine weitere Berechnung des Operanden zu gehen; und Durchführen der Totcode-Eliminierung und Globalkonstanten-Fortpflanzung, gekennzeichnet durch - nach der Identifizierung der Sätze (USE, DEF) und vor der Durchführung der Totcode- Eliminierung und der Globalkonstanten-Fortpflanzung - die Durchführung der folgenden Schritte für jeden engverbundenen Bereich mit einem einzigen Eingang, so daß der Bearbeitung jedes Bereichs, der eingebettete engverbundene Bereiche beinhaltet, die Bearbeitung aller solcher eingebetteten Bereiche folgt (i) Identifizierung aller Berechnungen in dem Bereich, die Ergebnisse erzeugen, die entweder zum Zugriff auf einen Speicher benutzte Adressen, die im Speicher abgespeichert werden, Argumente für Unterprogramme, oder Ausgänge zu externe Medien sind; (ii) Ausdrücken solcher Berechnungen als eine Summe von Produkten; (iii) Durchführung der folgenden Schritte für jede dieser Berechnungen, bis die Berechnung eine gegebene Anzahl Summanden gemäß Befehlstyp und Adressiermodi des Rechners, für den das Programm compiliert wird, beinhaltet; (iv) Auffinden des Paars schleifeninvarianter Terme, die in der Berechnung am häufigsten auftreten, und, wenn ein Term, der die Summe der Termpaare darstellt, nicht schon vorhanden ist, Generieren eines einzigen Terms, der die Summe der Termpaare darstellt, Versetzen des Codes zum Generieren des Einzelterms in den Kopfknoten für den Bereich, und Ersatz des Termpaars in der Berechnung durch den Einzelterm, der die Summe darstellt; und (v) wenn kein Paar schleifeninvarianter Terme gefunden werden kann, Finden des Termpaars, das in der Berechnung am häufigsten vorkommt, Einsetzen des Codes zum Generieren eines einzigen Terms, der die Summe der Termpaare nach jeder Berechnung jedes Termpaars im Bereich darstellt, Bestimmung ob beide Terme im Kopfknoten verfügbar sind, und wenn so, Einsetzen des Codes zum Generieren des Einzelterms, der die Summe im Kopfknoten darstellt.

ZUSAMMENFASSUNG DER ERFINDUNG

Die Aufgaben der vorliegenden Erfindung werden allgemein gelöst durch ein Optimierungsverfahren zur Anwendung in der 'Codeoptimierungsphase' einer allgemeinen Optimierungscompiler-Operation, die die Grundlagen der Reassoziation benutzt, um die bevorzugte Reihenfolge der Termkombinierung in einer Summe festzustellen, um auf diese Weise schleifeninvariante Unterberechnungen zu produzieren, oder allgemeine Unterausdrücke unter mehreren wesentlichen Berechnungen zu fördern, die nur einmal berechnet werden müssen. Um die gewünschte Optimierung eines Objektprogramms oder einer Programmsequenz zu erzielen, müssen die folgenden Schritte ausgeführt werden:
1. Bestimmung engverbundener Bereiche.
2. Bestimmung der USE- und DEF-Funktionen.
3. Identifizierung aller wesentlicher Berechnungen (ECs)
4. Neuschreiben der ECs in der normalen Form als Produkt summe.
5. Prüfung der Sammlung der ECs in normaler Form, um die Reihenfolge festzustellen, in der die darin enthaltenen Additionen gemacht werden müssen, und Identifizierung der zugeordneten Summanden.
6. Umschreiben der ECs, soweit möglich, in Form von Summanden, die in Schritt 5 gefunden wurden.
7. Umschreiben der Schleifenausgangsbedingungen in Form von den in Schritt 5 gefundenen Summanden.
8. Wiederholen der Schritte 2 bis 7 für jede Schleife im Programm, beginnend mit der innersten Schleife.
9. Eliminierung der Totcodes, und
10. Durchführung der Fortpflanzung der Globalkonstanten.

KURZE BESCHREIBUNG DER FIGUREN

Fig. 1 enthält ein Flußdiagramm auf höherer Ebene, das die allgemeine Organisation eines Optimierungscompilers darstellt.
Fig. 2 enthält ein Flußdiagramm desjenigen Teils der "Codeoptimierungsphase", der die vorliegende Erfindung beinhaltet.
Fig. 3 umfaßt ein Flußdiagramm, das die verschiedenen Schritte der "Reassoziation" zeigt, die auf einen engverbundenen Bereich (d.i. eine Schleife) angewandt werden müssen.
Fig. 4 umfaßt ein Flußdiagramm, das die erforderlichen Schritte zum Umstrukturieren einer Adressierungsberechnung in Übereinstimmung mit den Adressierungsmodi des Zielrechners darstellt.
Fig. 5 umfaßt ein detailliertes Flußdiagramm, das den Kern des Reassoziationsprozesses darstellt.
Fig. 6 umfaßt ein detailliertes Flußdiagramm des Stärkereduktionsverfahrens, das auf alle Berechnungen angewandt wird, die vom Reassoziationsprozeß benutzt werden.
Fig. 7 umfaßt ein detailliertes Flußdiagramm, das das Lineartest-Austauschverfahren darstellt.

OFFENBARUNG DER ERFINDUNG

Zwecks leichteren Verständnisses der Beschreibung der vorliegenden Erfindung werden die folgenden Ausdrücke, die in der Beschreibung und in den Ansprüchen benutzt werden, zunächst detailliert definiert. Viele dieser Ausdrücke sind auf dem Gebiet der Compileroptimierung allgemein geläufig, während andere für die hier geoffenbarte Erfindung besonders geoffenbart werden.

BEGRIFFSDEFINITIONEN

Eine 'Wesentliche Berechnung' erzeugt ein Ergebnis, das aus einem der folgenden Gründe erforderlich ist:
1. Es wird zum Zugriff auf einen Speicher benutzt (d.h. es handelt sich um eine Adresse),
2. Es wird im Speicher abgespeichert,
3. Es ist ein Argument in einem Unterprogramm, oder
4. Es wird an ein externes Medium ausgegeben.
Zum Beispiel, in der Anweisung:
Anzeigen (A + B + C);
ist das Ergebnis der Addition von A, B und C wesentlich, weil es ausgegeben werden muß. Es ist wahrscheinlich als (A + B) + C oder A + (B + C) implementiert,
weil die Summierer in den meisten Maschinen zwei Eingänge haben.
Jedoch sind weder A+B noch B+C wesentlich, auch wenn eines von ihnen auf dem Weg zum wesentlichen Ergebnis (A+B+C) berechnet werden muß.
Die Reassoziation stellt nun für das obige Beispiel fest, welche der Berechnungen
(A + B) + C, A + (B + C), oder (A + C) + B
in dem Zusammenhang, in dem sie vorkommt, die günstigste ist. Im nachstehenden Codefragment:
Do B = 1 to 10 display (A + B + C) end;
ist das bevorzugte Berechnungsverfahren (A+C)+B, weil A und C außerhalb der Schleife addiert werden können und nur eine einzige Addition in der Schleife erforderlich ist.
Die obigen Beispiele betreffen Berechnungen, die wesentlich sind, weil sie Ausgabewerte darstellen; in der Praxis kommen jedoch
meistens wesentliche Berechnungen vor, die Adressierberechnungen darstellen.

ENG VERBUNDENER BEREICH

Ein Subgraph, in dem ein Pfad zwischen beliebigen Knoten im Subgraph existiert, der keine Knoten außerhalb des Subgraphen einschließt.

ENG VERBUNDENER BEREICH MIT EINEM EINZIGEN EINGANG

Ein eng verbundener Bereich, in dem nur ein einziger Knoten vorhanden ist, dessen Vorgänger außerhalb des eng verbundenen Bereichs liegen. Ein eng verbundener Bereich mit einem einzigen Eingang entspricht dem allgemein bekannten Programmierbegriff einer Schleife. In der nachfolgenden Beschreibung wird das Akronym SCR benutzt und bedeutet einen eng verbundenen Bereich mit einem einzigen Eingang.

USE-FUNKTION

Die USE-Funktion für einen Programmpunkt P identifiziert alle Programmpunkte, in denen das in P berechnete Objekt als Operand benutzt wird.

DEF-FUNKTION

Die DEF-Funktion für einen Programmpunkt P und einen Operand O, der bei P benutzt wird, ist der Satz aller Programmpunkte, an denen O berechnet wird und von denen Programmpunkt P erreicht werden kann, ohne durch eine andere Berechnung von O zu gehen.

BEREICHSKONSTANTE

Eine Bereichskonstante, rc, im Hinblick auf einen SCR ist ein Objekt, das nicht im SCR berechnet wird; d.h., die DEF- Funktion für rc enthält keine Programmpunkte (Anweisungen) im SCR.

INDUKTIONSVARIABLE

Eine Induktionsvariable v für einen SCR ist eine Variable, deren einzigen Definitionen innerhalb des SCR durch lineare Beziehungen gegeben sind, wie z.B.
v = w + rc
v=w
wobei rc eine Bereichs konstante und w eine Induktionsvariable ist. w kann gleich v sein (was der allgemeinste Fall ist)

EINGANGSKNOTEN

der Eingangsknoten eines SCR ist der einzige Knoten innerhalb des SCR, der Vorgänger hat, die nicht im SCR liegen.

KOPFKNOTEN

Der Kopfknoten eines SCR ist der einzige Vorgänger des Eingangsknoten, der nicht im SCR enthalten ist. Wenn ein SCR keinen Kopfknoten aufweist, kann der Kontrollflußgraph leicht in einen äquivalenten Kontrollflußgraphen mit einem Kopfknoten umgeändert werden, wie dem Fachmann bekannt ist.

GLIEDERUNGSKNOTEN

Ein Gliederungsknoten eines Subgraphen ist ein Knoten, der bei jedem Durchgang durch den Subgraphen angefahren werden muß.

OFFENBARUNG DER ERFINDUNG

Die Figuren, die die Flußdiagramme der vorliegenden Erfindung zeigen, sind größtenteils selbsterklärend. Fig. 1 ist ein Flußdiagramm auf sehr hoher Ebene für einen Compiler, der auf dem Stand der Technik wohlbekannt ist. Die Blöcke 1, 2, 4 und 5 sind sehr einfach und wohlbekannt. Die Figur zeigt eindeutig, wo Block 3, betitelt "Codeoptimierung", der diejenige Phase der Compilervorgänge enthält, auf die sich die vorliegende Erfindung bezieht, in Bezug auf die Syntaxanalyse und Endcodegenerierung vorkommt.
In der nachfolgenden Beschreibung des allgemeinen "Codeoptimierungsverfahrens" werden die Zusammenhänge zwischen den beschriebenen Schritten und den verschiedenen Blöcken der Figuren jeweils in Klammern angegeben.
Die Reassoziation bestimmt die bevorzugte Reihenfolge der Kombination von Termen in einer Summe auf eine Weise, daß sie schleifeninvariante Unterberechnungen produziert, oder allgemeine Unterausdrücke unter den verschiedenen wesentlichen Berechnungen durch Anwenden des assoziativen Additionsgesetzes begünstigt. Gleichzeitig vereinfacht die hier geoffenbarte Erfindung einige der neu gebildeten Berechnungen durch Stärkereduktion, und berücksichtigt die Adressiermodi des Zielrechners. Damit dieses Ziel erreicht wird, müssen die folgenden Schritte ausgeführt werden:
Die nachfolgenden Schritte 1 und 2 werden durchgeführt in den Blöcken der FIG. 2, die denjenigen Teil der "Codeoptimierungsphase" zeigen, der die vorliegende Erfindung anwendet. Aus den Figuren ist ersichtlich, daß die Optimierungstransformationen, die den in dieser Figur detaillierten Optimierungstransformationen vorangehen oder ihnen folgen, für die Erfindung nicht wesentlich sind. Aber die Kontrollflußanalyse, die Bestimmung der engverbundenen Bereiche, und die Berechnung der USE- und DEF-Funktionen müssen der Reassoziation vorangehen, und die Totcode-Eliminierung und (Global)-Konstantenfortpflanzung müssen ihr folgen.
1. Flußgraph des Programms festlegen. Dann die engverbundenen Bereiche mit einem einzigen Eingang identifizieren unter Aufstellung einer Liste dieser Bereiche, so daß jeder Bereich, der engverbundene eingebettete Bereiche enthält, allen eingebetteten Bereichen in dieser Liste folgt. Eine solche Auflistung ist immer möglich: Siehe z.B. die oben zitierte Veröffentlichung von Hecht (Fig. 2 Block 1).

2. USE- und DEF-Funktionen bestimmen (Fig. 2 Block 2).

Schritte 3 bis 7 werden durch die detaillierte Folge in Fig. 3 erreicht. Die verschiedenen Schritte der Reassoziation, die auf einen engverbundenen Bereich (d.i. eine Schleife) angewandt werden müssen, sind unter Bezugnahme auf Fig. 4, 5, 6 und 7 eindeutig definiert.
3. Jetzt werden alle engverbundenen Bereiche mit einem einzigen Eingang der Reihe nach bearbeitet unter Dürchführung aller restlichen Schritte für die engverbundenen Bereiche mit einem einzigen Eingang (Blöcke 1 bis 8 in Fig. 3).
4. Bestimmung der Bereichskonstanten und Induktionsvariablen, die im engverbundenen Bereich mit einem einzigen Eingang (nachstehend 'der Bereich' genannt) vorkommen. Die Bereichskonstanten beinhalten alle Variablen, die Operanden im Bereich sind, für die aber die DEF-Funktion keine Definitionen mit dem Bereich hat (Fig. 3).
Alle im Bereich definierten Variablen sind potentielle Induktionsvariable. Aus dem Satz der Induktionsvariablen des Bereichs sind alle Variablen zu eliminieren, die aus anderen Berechhungen als Addition, Subtraktion oder Kopieren (im wesentlichen Addition mit Null) entstehen. Alle Variablen entfernen, die aus Operanden berechnet werden, die nicht Bereichs konstante oder potentielle Induktionsvariable sind.
5. Alle wesentlichen Berechnungen im Bereich identifizieren (Fig. 3).
6. Die wesentlichen Berechnungen als Produktsumme neu schreiben (Fig. 3). Für jeden Operanden in der wesentlichen Berechnung dessen Berechnungsdefinition einsetzen, wenn alle folgenden Bedingungen erfüllt sind (Block 4):
a. Es gibt nur eine Anweisung im Programm, die diesen Operanden definiert.
b. Die einzige Definition des Operanden liegt im gerade bearbeiteten Bereich (jedoch nicht in einem im Inneren des bearbeiteten Bereich enthaltenen Bereich).
c. Die einzige Anweisung, die den Operanden berechnet, ist entweder eine Addition, eine Subtraktion, eine Multiplikation oder eine Registerverschiebung.
7. Vorherige Schritte wiederholen, bis keine Operanden mehr dürch ihre Definitionen ersetzt werden können.
Fig. 4, die eine detaillierte Erklärung von Block 5 in Fig. 3 ist, zeigt, wie Konstante, die in Adressierberechnungen auftreten, in Übereinstimmung mit den Adressiermodi des Zielrechners gebracht werden.
Insbesondere zeigt sie, wie konstante Terme, die in die Adressierberechnung auftreten, gezwungen werden, daß sie innerhalb des zulässigen Adressierformats des Zielrechners fallen.
8. Alle wesentlichen Berechnungen in aufsteigender Reihenfolge anordnen, nach konstanten Termen (falls vorhanden) in der wesentlichen Berechnung sortieren. Beginnend mit dem kleinsten konstanten Term, wenn die wesentliche Berechnung zum Adressieren benutzt wird, bestimmen ob dieser konstante Term (nachstehend 'Verschiebung' genannt) direkt in einem Adressiermodus des Zielrechners benutzt werden kann. Wenn sie außerhalb des Bereichs liegt (Blöcke 1 bis 4 in Fig. 4):
a. Verschiebung durch die Summe der kleinsten gültigen Verschiebung für den Zielrechner und die Differenz zwischen der kleinsten gültigen Verschiebung und der Verschiebung in dieser Anweisung ersetzen. Diesegenannte Differenz wird mit D bezeichnet.
b. Die wesentlichen Berechnungen prüfen, die der modifizierten Berechnung in der Reihenauflistung folgen. Bei wesentlichen Berechnungen mit der Verschiebung d, wenn die Differenz d-D selbst eine gültige Verschiebung für den Adressiermechanismus des Zielrechners ist, die Verschiebung als die Summe von D und (d-D) neu schreiben.
Dann Schritt 8 erneut beginnen für aufeinanderfolgende wesentliche Berechnungen, beginnend mit der ersten wesentlichen Berechnung, die nicht in Schritt b bearbeitet wurde.
Das Reassoziationsverfahren ist in Fig. 5 als Diagramm dargestellt. Es umfaßt eine detaillierte Erklärung von Block 6 in Fig. 3 und bringt jede wesentliche Berechnung in Übereinstimmung mit der Architektur des Zielrechners, unter Auffinden und Auswerten gemeinsamer Unterausdrücke unter den wesentlichen Berechnungen. Sie zeigt, wie schleifeninvariante Unterausdrücke unter den wesentlichen Berechnungen bevorzugt behandelt werden und wie diese zwecks Berechnung in den Schleifenkopfknoten eingeschoben werden.
9. Jede wesentliche Berechnung, in ihrer endgültigen Form, kann als die Summe verschiedener Terme belassen werden, in Abhängigkeit davon, wo die wesentliche Berechnung benutzt wird. Z.B., eine Adresse eines Objekts im Hauptspeicher kann als die Summe von zwei der drei Termen belassen werden, wenn man den Adressierungsmodus des Systems/370 benutzt, vorausgesetzt, daß einer dieser drei Terme eine Verschiebung ist. Es kann erforderlich sein, daß weitere wesentliche Berechnungen in einem einzigen Register vorhanden sind. Im Falle einer Speicheradresse kann beobachtet werden, daß als Folge des Adressiermodus der Maschine mehrere Terme "frei addiert" werden können, wenn der Speicher adressiert wird. Für jede wesentliche Berechnung angeben, wieviele Terme "frei addiert" werden können (Fig. 5 Block 1), wenn eine wesentliche Berechnung aus mehr Termen besteht, als "frei addiert" werden können, (Fig. 5 Block 2).
a. Alle wesentlichen Berechnungen prüfen, die zu viele Terme für ein Termpaar haben, die beide schleifeninvariant sind (Fig. 5, Block 3). Wenn eine solches Paar gefunden wird, dann
1) Die Summe der Schleifeninvarianten generieren und sie an das Ende des Kopfknotens setzen (Fig. 5, Block 4).
2) In allen wesentlichen Berechnungen, in denen das gefundene Paar auftritt, das Termpaar durch einen einzigen Term ersetzen, der aus dem Register besteht, das die Summe des Termpaars enthält. Dann Schritt 9 wiederholen (Fig. 5, Block 5).
b. Die wesentlichen Berechnungen suchen, die zu viele Terme für das Termpaar aufweisen, das am häufigsten vorkommt, und (Fig. 5 Block 3 und 6)
1) Die Summe des Termpaars generieren. Berechnung zum Generieren der Summe hinter der Berechnung jedes Summanden in der Schleife einfügen. Der Ort, an dem die Summanden berechnet werden, kann aus der DEF-Funktion gefunden werden (Fig. 5, Block 7).
2) Wenn jedes Register in der Standarddarstellung der Summe eine Definition hat, die im Kopfknoten bekannt ist, dann die Berechnung der Summe in den Kopfknoten einfügen (Fig. 5, Block 8). In allen wesentlichen Berechnungen, in denen das gewählte Termpaar vorkommt, das Termpaar durch das Register ersetzen, das die Summe des Termpaars enthält. Dann Schritt 9 wiederholen (Blöcke 2 bis 8).
10. Jetzt, da jede wesentliche Berechnung als Termsumme geschrieben ist und die Anzahl der Terme für jeden Ausdruck nicht die Anzahl der "freien Additionen" überschreitet, die in den Anweisungen verfügbar sind, die das wesentliche Ergebnis produzieren, diese Anweisung unter Verwendung der in Schritt 9 entwickelten Register neu schreiben. Die Umstrukturierung der Terme in einer wesentlichen Berechnung ist der Kern des Reassoziationsprozesses (Fig. 5, Block 9).
Der folgende Schritt 11 wird in Fig. 6 erklärt, die den Schritt zur Stärkereduktion detailliert darstellt, die ihrerseits auf alle Berechnungen angewendet wird, die vom Reassoziationsprozeß benutzt werden. Die Stärkereduktion ermöglicht es, daß alle Polynome vom n-ten Grad der Induktionsvariablen mit n Additionen und ohne Multiplikationen in der Schleife berechnet werden. Im allgemeinen Fall eines linearen Ausdrucks wird eine Adressierungsberechnung durch eine einzige Addition von Iteration zu Iteration gültig gehalten.
11. Für jedes neue in Schritt 9 oder in Schritt 11 eingeführte Register R (Fig. 6, Block 7), das keine Schleifeninvariante ist, Definitionspunkte in der Schleife für alle Register r suchen, die bei der Berechnung von R benutzt wurden. Wenn R linear in r ist, dann kann ein neuer Wert R aus seinem derzeitigen Wert berechnet werden als:
R = R + (erste Differenz von R zur).
In fast allen Fällen ist diese erste Differenz eine Schleifeninvariante und läßt sich im Schleifenkopfknoten einfach berechnen. (Die erste Differenz ist in Wirklichkeit meistens eine Konstante) (Fig. 6, Blöcke 3- 6). Wenn die erste Differenz keine Schleifeninvariante ist, dann muß sie im Schleifen-Vorkopf initialisiert werden, und das Register, das die erste Differenz enthält, muß an allen Definitionspunkten seiner Variablen innerhalb der Schleife neu berechnet werden (Fig. 6, Block 7). Wenn die erste Differenz kein Polynom ist, dann muß das Register R an den Definitionspunkten aller Register r, die in R vorkommen, ohne Hilfe der Anwendung seiner ersten Differenz neu berechnet werden (Fig. 6, Block 8).
Wenn es möglich ist, die erste Differenz zur Neuberechnung von R auszuwerten, dann sagen wir, daß der Ausdruck für R stärkereduziert wurde.
Die Einzelheiten für Schritt 12 sind in Fig. 7 eindeutig dargestellt, die den linearen Testersatzprozeß beschreibt, durch den die Schleifenendbedingung oft als eine neue, durch Reassoziation eingeführte Induktionsvariable neu geschrieben werden kann. Auf diese Weise macht das Transformationsprogramm möglicherweise nur die neuen Induktionsvariablen erforderlich, und die ursprünglichen werden tot und ihre Berechnungen unterliegen der Totcode-Eliminierung.
12. Wenn eine Schleifenausstiegbedingung als Induktionsvariable geschrieben wird und die Induktionsvariable zur Berechnung eines Eingangs R einer wesentlichen Berechnung benutzt wird, dann läßt sich die Schleifenausstiegbedingung als R umcodieren, vorausgesetzt, daß bestimmt werden kann, daß die erste Differenz von R zur Induktionsvariablen eine positive Konstante ist (Fig. 7, Blöcke 1 und 2).
Durch Umschreiben der Schleifenendbedingung als neues Register, das durch Reassoziation erzeugt wird, kann es sein, daß für die ursprüngliche Induktionsvariable keine wesentliche Anwendung mehr übrigbleibt (Fig. 7, Blöcke 3 und 4). Das kann nachgeprüft werden durch Verfolgen der DEF-USE Ketten und beobachten, ob die Induktionsvariable in einer wesentlichen Berechnung ein Operand ist. (Sie ist noch ein Operand für eine Anweisung, durch die die Induktionsvariable selbst um eine konstante Größe vergrößert wird.) Wenn keine wesentlichen Anwendungen für eine Induktionsvariable übrigbleiben, kann sie als tot aus dieser Schleife entfernt werden (siehe Fig. 7, Blöcke 5 und 6).
13. Alle Schritte 4 bis 12 für jeden Programmbereich wiederholen, beginnend mit den am weitesten innen liegenden Bereichen. Wenn ein Bereich einen bereits früher bearbeiteten Bereich enthält, müssen auch die neuen Berechnungen, die im Kopf der inneren Schleife eingefügt sind, als Kandidaten für die Reassoziation betrachtet werden.
Die folgenden Schritte werden in Fig. 2, Block 4 ausgeführt.
14. Tote Berechnungen eliminieren. Das entfernt ursprüngliche Ermittlungen wesentlicher Berechnungen, wenn das Original nicht als Unterausdruck einer wesentlichen Berechnung vorkommt.
15. Tote Induktionsvariable eliminieren (Fig. 7, Blöcke 5 und 6). Das erfordert die Prüfung der USE-DEF-Ketten für jede Induktionsvariable um
festzustellen, daß ihre einzige Anwendung darin besteht, sich selbst zu aktualisieren (Siehe Anmerkungen in Schritt 12).
16. Durchführen der Globalkonstantenfortpflanzung. In Schleifenköpfe eingefügte Codes bedingen häufig Berechnungen mit Konstanten.
17. Durchführen globaler Eliminierung gemeinsamer Unterausdrücke und Codeverschiebung. Die neu eingeführte Verfahren der Ermittlung wesentlicher Berechnungen wurde entworfen, um gemeinsame Unterausdrücke und neue Schleifeninvarianten zu erzeugen.
Hiermit ist die detaillierte Beschreibung des vorliegenden "Reassoziations"-Verfahrens abgeschlossen, das in der "Codeoptimierungsphase" im Betrieb eines typischen Optimierungscompilers benutzt wird. Das folgende ist ein Beispiel, das in stark vereinfachter Form zeigt, wie die geoffenbarte Erfindung ein kurzes Codesegment verbessert.

BEISPIEL

Beispiel 1 enthält ein einfaches Programm, das für eine Verbesserung durch Reassoziation zugänglich ist.
Das Programm besteht aus zwei ineinandergeschachtelten Schleifen, deren Zweck es ist, alle streng positiven Zahlen in einem Datenfeld um 1 zu erhöhen.
Auflistung 1 ist eine Zwischenspracheauflistung dieses Programms, nachdem Kasten zwei in Fig. 2 abgeschlossen wurde. Die Optimierungen der Codeverschiebungen und Eliminierung redundanter Ausdrücke wurden bereits abgeschlossen.
Auflistung 2 ist die Zwischenspracheauflistung dieses Programms nach Durchführung der Reassoziation. Das Programm hat sich scheinbar verschlechtert, aber das ist deswegen, weil der alte Code nicht entfernt wurde (er kann möglicherweise für andere Zwecke als die Adressenberechnung noch gebraucht werden), und ein Großteil des eingefügten Codes kann durch Konstantenfortpflanzung vereinfacht werden. Ferner können die vielen MR (Move Register - Registerverschiebung) Anweisungen als Ergebnis einer Registerzuweisung verschwinden, wenn die Quelle und das Ziel der MR dem gleichen Register zugeordnet werden können.
Der Code zwischen den Marken %4 und %10 wurde hinzugefügt, um die neuen Adressenberechnungen, die in der inneren Schleife benutzt werden, zu initialisieren sowie auch zur Berechnung der neuen Vergleichsgröße zwecks Feststellung, wann die innere Schleife zu beenden ist. Bemerkt wird, daß diese Berechnungen selbst linear in Registern sind, die in der äußeren Schleife gesetzt sind. Daraus folgt, daß eben die Berechnungen, die zwischen den Marken %4 und %10 eingefügt sind, selbst der Reassoziation unterliegen und die Initialisierungen der sich ergebenden neuen Berechnungen zwischen den Marken %3 und %11 auftreten. Die Wirkung ist, daß die meisten der ursprünglich zwischen die Marken %4 und %10 gesetzten Anweisungen tot werden. Ferner können viele der eingeschobenen Anweisungen während des Compilierens ausgeführt werden (Konstantenfortpflanzung).
Auflistung 3 stellt den Code nach Durchführung der Konstantenfortpflanzung und Wertenumerierung dar. Eine große Anzahl Registerverschiebungsanweisungen (MR in der Figur) bleiben erhalten. Viele dieser Variablen sind nutzlose Induktionsvariable geworden, deren Ergebnisse nie verwendet werden. In anderen Fällen ist es einer Registerzuteilung möglich, die Quelle und das Ziel der MR dem gleichen physikalischen Register zuzuweisen, so daß die MR keinen Code generieren muß.
Auflistung 4 stellt den endgültigen Code nach Durchführung der Totcode-Eliminierung, Totinduktionsvariablen-Eliminierung und Registerzuweisung dar. Abgesehen von der Transformation des Codes aus Auflistungen 1 und 2 sind die übrigen Transformationen Standardoptimierungstransformationen, die in Arbeitscompilierern vorkommen. Das hier gelehrte Reassoziationsverfahren betrifft nicht selbst direkt das Ausscheiden der überschüssigen Codes, die beim Übergang von Auflistung 1 zu Auflistung 2 eingeschoben werden. Die Verfahren der Reassoziation sind einfach und allgemein. Das Ausscheiden der überflüssigen Codes und die übergeordnete Adressengenerierung zusammen mit dem Belassen aller noch gebrauchten Originalcodes ist die Aufgabe der Anwendung in der Umgebung eines Optimierungscompilers. BEISPIEL 1: Ein einfaches Programm zum Demonstrieren der Reassoziation example: proc integer static integer end Auflistung 1: Zwischensprachencode für das Programm aus Beispiel 1 vor Reassoziation EXAMPLE STATIC EXAMPLE Auflistung 2: Zwischencode für das Programm Beispiel 1 unmittelbar nach Reassoziation EXAMPLE EXAMPLE Auflistung 3: Zwischensprachencode nach Reassoziation, Konstantenfortpflanzung und Wertenumerierung EXAMPLE EXAMPLE Auflistung 4. Endgültiger Code für Programm Beispiel 1, nach aller Optimierung und Registerzuweisung für ein Rechnersystem IBM RTPC EXAMPLE PEND EXAMPLE EXAMPLE End of Code

Claims

1. Ein Verfahren zum Compilieren eines Rechnerprogramms, wobei das Verfahren eine Optimierungsphase einschließlich der folgenden Schritte aufweist: Durchführung der Kontrollflußanalyse zwecks Identifizierung eng verbundener Bereiche des Programms mit einem einzigen Eingang; Identifizieren, für jeden Programmpunkt und jeden darauf angewandten Operanden, des Satzes (USE) aller Programmpunkte, bei denen das bei P berechnete Objekt als Operand benutzt wird, und des Satzes (DEF) aller Programmpunkte, an denen der Operand berechnet wird und von denen aus der Programmpunkt erreicht werden kann, ohne durch eine weitere Berechnung des Operanden zu gehen; und Durchführen der Totcode-Eliminierung und Globalkonstanten-Fortpflanzung, gekennzeichnet durch - nach der Identifizierung der Sätze (USE, DEF) und vor der Durchführung der Totcode-Eliminierung und der Globalkonstanten-Fortpflanzung - die Durchführung der folgenden Schritte für jeden engverbundenen Bereich mit einem einzigen Eingang, so daß der Bearbeitung jedes Bereichs, der eingebettete engverbundene Bereiche beinhaltet, die Bearbeitung aller solcher eingebetteten Bereiche folgt:

(i) Identifizierung aller Berechnungen in dem Bereich, die Ergebnisse erzeugen, die entweder zum Zugriff auf einen Speicher benutzte Adressen, die im Speicher abgespeichert werden, Argumente für Unterprogramme, oder Ausgänge zu externe Medien sind;

(ii) Ausdrücken solcher Berechnungen als eine Summe von Produkten;

(iii) Durchführung der folgenden Schritte für jede dieser Berechnungen, bis die Berechnung eine gegebene Anzahl Summanden gemäß Befehlstyp und Adressiermodi des Rechners, für den das Programm compiliert wird, beinhaltet;

(iv) Auffinden des Paars schleifeninvarianter Terme, die in der Berechnung am häufigsten auftreten, und, wenn ein Term, der die Summe der Termpaare darstellt, nicht schon vorhanden ist, Generieren eines einzigen Terms, der die Summe der Ternpaare darstellt, Versetzen des Codes zum Generieren des Einzelterms in den Kopfknoten für den Bereich, und Ersatz des Termpaars in der Berechnung durch den Einzelterm, der die Summe darstellt; und

(v) wenn kein Paar schleifeninvarianter Terme gefunden werden kann, Finden des Termpaars, das in der Berechnung am häufigsten vorkommt, Einsetzen des Codes zum Generieren eines einzigen Terms, der die Summe der Termpaare nach jeder Berechnung jedes Termpaars im Bereich darstellt, Bestimmung ob beide Terme im Kopfknoten verfügbar sind, und wenn so, Einsetzen des Codes zum Generieren des Einzelterms, der die Summe im Kopfknoten darstellt.

2. Ein Verfahren gemäß Anspruch 1, enthaltend, zwischen Schritt (ii) und Schritt (iii), die folgenden Schritte: Substituierung der Definition jedes Operanden in den identifizierten Berechnungen, für die es eine einzige Berechnung des Operanden in dem Bereich gibt und die definierende Operation Addition, Subtraktion, Multiplikation oder Registerverschiebung ist.

3. Ein Verfahren gemäß Anspruch 1 oder Anspruch 2, enthaltend, zwischen Schritt (ii) und Schritt (iii), den Schritt des Fixierens von Verschiebungen, um den von dem Adressiermodus des Rechners vorgegebenen Randbedingungen zu entsprechen, für den das Programm compiliert werden soll, durch Durchführung der folgenden Schritte für jeden eng verbundenen Bereich:

(a) Sortieren der Berechnungen im Bereich, die Ergebnisse erzeugen, die entweder Adressen zur Benutzung beim Zugriff auf den Speicher sind, die im Speicher abgespeichert werden, die Argumente für Unterprogramme sind, oder die in aufsteigender Reihenfolge ihrer Konstantausdrücke an externe Medien ausgegeben werden;

(b) Prüfen der Liste in der sortierten Ordnung; und

(c) wenn die Berechnung eine Adresse darstellt, Bestimmung, ob jeder konstante Term in einem Adressenmodus des Rechners dargestellt werden kann, und wenn nicht, (i) Darstellung der konstanten Terme als die Summe der kleinsten gültigen Konstante, die im Rechner dargestellt werden kann, mit der Differenz D zwischen der kleinsten gültigen Verschiebung und dem konstanten Term; und (ii) Ersatz des konstanten Terms d in aufeinanderfolgenden Berechnungen in der Liste durch die Summe aus D und (d - D) wenn (d - D) in einem Adressiermodus des Rechners darstellbar ist.

4. Einen optimierenden Compiler, der so ausgelegt ist, daß er ein Verfahren gemäß einem der obigen Ansprüche ausführt.