DE112012000209T5

DE112012000209T5 - Ein nachfragegesteuerter Algorithmus zum Reduzieren der Vorzeichenerweiterungsinstruktionen, die in Programmschleifen eines 64-Bit-Computerprogramms enthalten sind

Info

Publication number: DE112012000209T5
Application number: DE112012000209T
Authority: DE
Inventors: Akella Sastry; Yuan Lin
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2011-11-07
Filing date: 2012-11-06
Publication date: 2013-08-22
Also published as: US10228919B2; TWI502509B; US20190087164A1; CN103348317B; WO2013070621A2; US20130117548A1; WO2013070635A1; US9639336B2; DE112012000195T5; WO2013070616A1; TWI498817B; US20130117734A1; TWI483182B; CN103608774A; TW201333877A; CN103339621A; DE112012000214T5; US20130113809A1; TW201337764A; US9009686B2

Abstract

Eine Ausführungsform der vorliegenden Erfindung legt eine Technik zum Reduzieren von Vorzeichenerweiterungsinstruktionen (SEIs) dar, die in einem Computerprogramm enthalten sind, die Technik enthält Erhalten eines intermediären Codes, der mit dem Computerprogramm assoziiert ist und eine erste SEI enthält, die in einer Programmschleifenstruktur innerhalb des Computerprogramms enthalten ist, Feststellen, dass die erste SEI dazu geeignet ist, aus der Programmschleifenstruktur heraus bewegt zu werden, Einfügen einer zweiten SEI in einen Pre-Header der Programmschleife hinein, wobei die zweite SEI, wenn sie von einem Prozessor ausgeführt wird, einen ursprünglichen Wert, auf den die erste SEI zielt, von einem kleineren Typ zu einem größeren Typ befördert, und Ersetzen der ersten SEI durch eine oder mehrere intermediäre Instruktionen, die für zusätzliche Compiler-Optimierungen geeignet sind.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung nimmt die Priorität der US-Provisional-Patentanmeldung mit dem Aktenzeichen 61/556,782, welche am 7. November 2011 eingereicht wurde, sowie die Priorität der US-Patentanmeldung mit dem Aktenzeichen 13/661,478, welche am 26. Oktober 2012 eingereicht wurde, in Anspruch. Jede dieser Anmeldungen wird hiermit durch Bezugnahme hierin aufgenommen.
HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich im Allgemeinen auf Rechnerverarbeitung und spezifischer auf einen nachfragegesteuerten (engl. „demand-driven”) Algorithmus zum Reduzieren der Vorzeichenerweiterungsinstruktionen (engl. „sign-extension instructions”), die in Programmschleifen eines 64-Bit-Computerprogramms enthalten sind.
Beschreibung des verwandten Standes der Technik
Entwickler verwenden Compiler zur Erzeugung von ausführbaren Programmen aus höherem Quellcode (engl. „high-level source code”). Ein Compiler ist typischerweise dazu konfiguriert, einen höheren Quellcode eines Programms (zum Beispiel in C++ oder Java geschrieben) zu erhalten, eine Ziel-Hardwareplattform (zum Beispiel einen x86-Prozessor) zu bestimmen, auf welcher das Programm auszuführen ist, und dann den höheren Quellcode in einen Assemblercode (engl. „assembly-level code”), der auf der Ziel-Hardwareplattform ausgeführt werden kann, zu übersetzen. Diese Konfiguration bietet den Vorteil, dass es Entwickler ermöglicht wird, ein einziges höheres Quellcode-Programm zu schreiben und dieses Programm dann zur Ausführung auf einer Vielfalt von Hardwareplattformen vorzugeben, wie zum Beispiel mobilen Geräten, persönlichen Rechnern oder Servern.
Ein Compiler enthält im Allgemeinen drei Teile: ein Frontend (engl. „front-end”), ein Mittelend (engl. „middle-end”) und ein Backend (engl. „back-end”). Das Frontend ist konfiguriert zum Sicherstellen, dass der höhere Quellcode Programmiersprache-Syntax und -Semantik erfüllt, worauf die Frontendeinheit eine erste intermediäre Darstellung (engl. „intermediate representation”) (IR) des höheren Quellcodes erzeugt. Das Mittelend ist zum Erhalten und Optimieren der ersten IR konfiguriert, was üblicherweise zum Beispiel ein Entfernen von unerreichbarem (engl. „unreachable”) Code umfasst, der, falls vorhanden, in der ersten IR enthalten ist. Nach dem Optimieren der ersten IR erzeugt das Mittelend eine zweite IR, die von dem Backend verarbeitet werden soll. Das Backend erhält insbesondere die zweite IR und übersetzt die zweite IR in einen Assemblercode. Der Assemblercode enthält niedrigere (engl. „low-level”) Assemblerinstruktionen, die auf einem Prozessor, der Teil der Ziel-Hardwareplattform ist, direkt ausgeführt werden können.
In einigen Fällen werden Programme in einem „64-Bit-Modus” ausgeführt, in dem Basis-Speicheradressen 64-Bit-Werte (zum Beispiel int64-Variable) sind und Speicheroffsets 32-Bit-Werte (zum Beispiel int32-Variable) sind. Demzufolge fordert eine typische Berechnung von einer Adresse, zum Beispiel von einer bestimmten aus einem Index von einem Array, eine Addition eines 32-Bit-Speicheroffsets zu einer 64-Bit-Basisadresse. Damit der Prozessor diese Addition durchführen kann, muss der Prozessor erst das 32-Bit-Speicheroffset in ein 64-Bit-Speicheroffset umwandeln, so dass die Anzahl der Bits, die mit dem Speicheroffset assoziiert ist, an die Anzahl der Bits, die mit der 64-Bit-Basisadresse assoziiert ist, angepasst ist. Eine solche Umwandlung wird hierin als „Vorzeichenerweiterung” (engl. „sign-extension”) bezeichnet, welche insbesondere ein Erhöhen der Anzahl von Bits von einer Binärzahl aufweist, während das Vorzeichen (das heißt, positiv/negativ) und der Wert der Zahl bewahrt werden.
Obwohl eine Vorzeichenerweiterungsoperation keine besonders teure Operation ist, hindert eine Vorzeichenerweiterungsoperation, die in einer Programmschleife enthalten ist, wichtige Programmschleifenoptimierung, die als „Programmschleifenstärkereduktion” (engl. „loop strength reduction”) bekannt ist. Insbesondere weist fast aller Code, der im „64-Bit-Modus” ausgeführt wird, eine erhebliche Anzahl von Programmschleifen auf, und viele dieser Programmschleifen enthalten Vorzeichenerweiterungsinstruktionen. Eine Technik zum Eliminieren einer Vorzeichenerweiterung von einer 32-Bit-Variable in eine 64-Bit-Variable innerhalb einer Programmschleife beinhaltet eine Umwandlung der Variable in eine 64-Bit-Variable außerhalb der Programmschleife durch Ausführen einer Vorzeichenerweiterung in einem Pre-Header von der Programmschleife und Ersetzen aller 32-Bit-Operationen auf der ursprünglichen 32-Bit-Variable durch 64-Bit-Operationen auf der beförderten Variable. Diese Transformation macht aber die wichtige Annahme, dass keine der ursprünglichen 32-Bit-Operationen Ganzzahlüberlauf verursachen. Diese Annahme ist für gängige Programmiersprachen gültig, wie zum Beispiel C und C++, bei denen ein jegliches Programm, das auf Überlauf von Vorzeichen-Arithmetik-Operatoren (engl. „signed-arithmetic operators”) baut, undefiniert ist. Bei solchen Architekturen, wo 64-Bit-Register und -Operationen keine extra Kosten verursachen, ist diese Optimierung immer ein Erfolg. Bei Architekturen, wo 64-Bit-Register und -Operationen Additionsressourcen benötigen, muss sorgfältige Überlegung verwendet werden, und eine Kosten-Nutzen-Analyse zum wahlweisen Auswählen dieser Optimierung ist wünschenswert, da die Verwendung von 64-Bit-Registern und -Operationen den Registerdruck (engl. „register pressure”) erhöhen und mehr Zyklen verbrauchen kann.
Folglich ist das, was auf dem technischen Gebiet benötigt wird, eine Technik zum Identifizieren von Vorzeichenerweiterungsinstruktionen, die eliminiert werden sollen, unter Verwendung von Kosten-Nutzen-Analyse, und ein Verfahren zum Durchführen der Transformation auf niedrigerer intermediärer Darstellung (IR) eines Programms.
ZUSAMMENFASSUNG DER ERFINDUNG
Eine Ausführungsform der vorliegenden Erfindung legt ein Verfahren zum Reduzieren von Vorzeichenerweiterungsinstruktionen (SEIs) dar, die in einem Computerprogramm enthalten sind. Das Verfahren weist folgende Schritte auf: Erhalten eines intermediären Codes, der mit dem Computerprogramm assoziiert ist und eine erste SEI enthält, die in einer Programmschleifenstruktur innerhalb des Computerprogramms enthalten ist, Feststellen, dass die erste SEI dazu geeignet ist, aus der Programmschleifenstruktur heraus bewegt zu werden, Einfügen einer zweiten SEI in einen Pre-Header der Programmschleife hinein, wobei die zweite SEI, wenn sie von einem Prozessor ausgeführt wird, einen ursprünglichen Wert, auf den die erste SEI zielt, von einem kleineren Typ zu einem größeren Typ befördert, und Ersetzen der ersten SEI durch eine oder mehrere intermediäre Instruktionen, die für zusätzliche Compiler-Optimierungen geeignet sind.
Ein Vorteil der offenbarten Ausführungsformen ist, dass ein Compiler automatisch Vorzeichenerweiterungsinstruktionen identifiziert, die in Programmschleifen von einem Computerprogramm enthalten sind, und die Vorzeichenerweiterungsinstruktionen nach Außerhalb der Programmschleifen verschieben, in welchen sie ursprünglich enthalten sind. Der Compiler modifiziert dann die Instruktionen innerhalb der Programmschleifen, um die entfernten Vorzeichenerweiterungsinstruktionen zu berücksichtigen, so dass die Richtigkeit des Computerprogramms intakt verbleibt. Als ein Ergebnis mag die Anzahl der Taktzyklen, die von dem Prozessor benötigt wird, um das Programm auszuführen, reduziert werden, was in direkter Korrelation mit Gesamtenergieeinsparungen steht.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
So dass die Art und Weise, in der die oben angeführten Merkmale der vorliegenden Erfindung im Detail verstanden werden kann, mag eine detailliertere Beschreibung der oben kurz zusammengefassten Erfindung durch Bezugnahme auf Ausführungsformen gehabt haben, von denen einige in der angehängten Zeichnungen dargestellt sind. Es muss aber bemerkt werden, dass die angehängten Zeichnungen nur typische Ausführungsformen der Erfindung illustrieren und somit nicht als den Umfang der Erfindung beschränkend angesehen werden dürfen, da die Erfindung andere gleich effektive Ausführungsformen zulassen mag.
1 ist ein Blockdiagramm, das ein Computersystem darstellt, das zum Implementieren eines oder mehrerer Aspekte der vorliegenden Erfindung konfiguriert ist.
Die 2A–2D zeigen ein Flussdiagramm von Verfahrensschritten zur Reduktion von Vorzeichenerweiterungsinstruktionen, die in Programmschleifen eines 64-Bit-Computerprogramms enthalten sind, gemäß einer Ausführungsform der vorliegenden Erfindung.
DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein eingehenderes Verständnis der vorliegenden Erfindung bereitzustellen. Es wird aber für einen Fachmann offenkundig sein, dass die vorliegende Erfindung auch ohne ein oder mehrere von diesen spezifischen Details ausgeübt werden kann.
Systemübersicht
1 ist ein Blockdiagramm, das ein Computersystem 100 zeigt, das zum Implementieren eines oder mehrerer Aspekte der vorliegenden Erfindung konfiguriert ist. Das Computersystem 100 weist eine zentrale Verarbeitungseinheit (engl. „central processing unit”) (CPU) 102 und einen Systemspeicher 104 auf, die über einen Verbindungspfad (engl. „interconnection path”), der eine Speicherbrücke 105 aufweisen mag, miteinander in Verbindung stehen bzw. kommunizieren. Die Speicherbrücke 105, die zum Beispiel ein Northbridge-Chip sein mag, ist über einen Bus oder einen anderen Kommunikationspfad 106 (zum Beispiel einen HyperTransport-Links) mit einer I/O-(Input/Output)-Brücke 107 verbunden. Die I/O-Brücke 107, welche zum Beispiel ein Southbridge-Chip sein mag, erhält User-Input von einer oder mehreren User-Input-Vorrichtungen 108 (zum Beispiel Tastatur, Maus) und leitet den Input über den Kommunikationspfad 106 und die Speicherbrücke 105 an die CPU 102 weiter. Ein Parallelverarbeitungssubsystem 112 ist über einen Bus oder einen zweiten Kommunikationspfad 113 (zum Beispiel einen Peripheral Component Interconnect (PCI) Express, einen beschleunigten Grafikport (engl. „Accelerated Graphics Port”), oder einen HyperTransport-Link) an die Speicherbrücke 105 gekoppelt; in einer Ausführungsform ist das Parallelverarbeitungssubsystem 112 ein Grafiksubsystem, das Pixel zu einer Displayvorrichtung 110 liefert, die jede konventionelle Kathodenstrahlröhre, Flüssigkristalldisplay, LED-Display (engl. „light-emitting diode display”) oder ähnliches sein mag. Eine Systemdisk 114 ist auch mit der I/O-Brücke 107 verbunden und mag konfiguriert sein zum Speichern von Inhalt und Applikationen und Daten zur Verwendung durch die CPU 102 und das Parallelverarbeitungssubsystem 112. Die Systemdisk 114 stellt nichtflüchtiger Speicher für Applikationen und Daten bereit und mag feste oder ausbaubare Festplattenlaufwerke, Flash-Speichervorrichtungen, und CD-ROM (engl. „compact disc read-only-memory”), DVD-ROM (engl. „digital versatile disc-ROM”), Blu-ray, HD-DVD (engl. „high definition DVD) oder andere magnetische, optische oder Festkörper-Speichervorrichtungen aufweisen.
Ein Switch 116 stellt Verbindungen zwischen der I/O-Brücke 107 und anderen Bauteilen, wie zum Beispiel einem Netzwerkadapter 118 und verschiedenen Erweiterungskarten (engl. „add-in cards”) 120 und 121, bereit. Andere (nicht explizit dargestellte) Bauteile, einschließlich „universal serial bus” (USB) oder anderer Portanschlüsse (engl. „port connections”), „compact disc”(CD)-Laufwerke, „digital versatile disc”-(DVD)-Laufwerke, Filmaufzeichnungsvorrichtungen und ähnliches, mögen auch mit der I/O-Brücke 107 verbunden sein. Die verschiedene Verbindungspfade, die in 1 gezeigt sind, einschließlich der spezifisch gekennzeichneten Verbindungspfaden 106 und 113, mögen unter Verwendung von jeglichen geeigneten Protokollen, wie zum Beispiel PCI-Express, AGP (engl. „Accelerated Graphics Port”), HyperTransport oder jedem anderen Bus oder Punkt-zu-Punkt-Kommunikationsprotokoll(en) (engl. „Point-to-Point Communication Protocol(s)”) implementiert sein, und Verbindungen zwischen verschiedenen Vorrichtungen mögen verschiedene Protokolle benutzen, wie es aus dem Stand der Technik bekannt ist.
Das Parallelverarbeitungssubsystem 112 weist in einer Ausführungsform Schaltkreise auf, die für Grafik- und Videoverarbeitung optimiert sind, einschließlich zum Beispiel Videoausgabeschaltkreise, und stellt eine Grafikverarbeitungseinheit (GPU) dar. In einer anderen Ausführungsform weist das Parallelverarbeitungssubsystem 112 Schaltkreise auf, die für Universalverarbeitung (engl. „general purpose processing”) optimiert sind, während die unterliegende rechnerische Architektur aufrechterhalten wird (wie es hierin detaillierter beschrieben wird). In noch einer anderen Ausführungsform mag das Parallelverarbeitungssubsystem 112 mit einem oder mehreren anderen Systemelementen in einem einzigen Subsystem integriert sein, wie zum Beispiel durch Zusammenführung der Speicherbrücke 105, der CPU 102 und der I/O-Brücke 107, um ein System-auf-Chip (engl. „system on chip”) (SoC) zu bilden.
In einer Ausführungsform weist das Parallelverarbeitungssubsystem 112 eine oder mehrere Parallelverarbeitungseinheiten („Parallel Processing Units”) (PPUs) auf, wobei jede von denen an einen lokalen Parallelverarbeitungs-(PP)-Speicher 204 gekoppelt ist. Im Allgemeinen weist ein Parallelverarbeitungssubsystem 112 eine Anzahl U von PPUs auf, wobei U ≥ 1. In einigen Ausführungsformen sind einige oder alle der PPUs in dem Parallelverarbeitungssubsystem 112 Grafikprozessoren mit Rendering-Pipelines, die konfiguriert werden können zum Ausführen verschiedener Operationen im Zusammenhang mit Erzeugung von Pixeldaten aus Grafikdaten, die von der CPU 102 und/oder dem Systemspeicher 104 über die Speicherbrücke 105 und den zweiten Kommunikationspfad 113 bereitgestellt werden, zum Interagieren mit dem lokalen Parallelverarbeitungsspeicher (der als Grafikspeicher verwendet werden kann, einschließlich zum Beispiel eines konventionellen Framepuffer), um Pixeldaten zu speichern und aktualisieren, zum Beliefern einer Displayvorrichtung 110 mit Pixeldaten, und ähnliches. In einigen Ausführungsformen mag das Parallelverarbeitungssubsystem 112 eine oder mehrere PPUs, die als Grafikprozessoren operieren, und eine oder mehrere PPUs, die für Universalberechnungen (engl. „general-purpose computations”) verwendet werden, aufweisen. Die PPUs mögen identisch oder unterschiedlich sein, und jede PPU mag eine dedizierte Parallelverarbeitungsspeichervorrichtung(en) aufweisen.
Es wird verstanden werden, dass das System von 1 illustrativ ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl von CPUs 102 und der Anzahl von Parallelverarbeitungssubsystemen 112, mag, wie gewünscht, variiert werden. In einigen Ausführungsformen ist der Systemspeicher 104 zum Beispiel direkt mit der CPU 102 verbunden, statt durch eine Brücke, und andere Vorrichtungen kommunizieren mit dem Systemspeicher 104 über die Speicherbrücke 105 und die CPU 102. In anderen alternativen Topologien ist das Parallelverarbeitungssubsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 verbunden, statt mit der Speicherbrücke 105. In noch anderen Ausführungsformen mögen die I/O-Brücke 107 und Speicherbrücke 105 in einem einzigen Chip integriert sein, statt als eine oder mehrere diskrete Vorrichtungen zu existieren. Große Ausführungsformen mögen zwei oder mehr CPUs 102 und zwei oder mehr Parallelverarbeitungssubsysteme 112 aufweisen.
Die jeweiligen hierin gezeigten Bauteile sind optional; zum Beispiel mag jede Anzahl von Erweiterungskarten oder Peripherievorrichtungen unterstützt werden. In einigen Ausführungsformen ist der Switch 116 entfernt und der Netzwerkadapter 118 und die Erweiterungskarten 120, 121 sind direkt mit der I/O-Brücke 107 verbunden.
Reduzieren von Vorzeichenerweiterungsinstruktionen, die in Programmschleifen eines 64-Bit-Computerprogramms enthalten sind
Wie es hierin detaillierter dargelegt wird, weist die vorliegende Erfindung einen Compiler 150 auf, der in dem Computersystem 100 der 1 ausgeführt wird. Der Compiler 150 ist dazu konfiguriert, einen Algorithmus zu implementieren, um die intermediären Instruktionen zu vereinfachen, die ein Computerprogramm bilden. Der Compiler 150 ist insbesondere dazu konfiguriert, Programmschleifen in dem intermediären Code zu identifizieren, die mindestens eine Vorzeichenerweiterungsinstruktion enthalten, die dazu geeignet ist, aus dem Programmschleifen heraus bewegt zu werden. Die Programmschleifen werden in einer innerste-Programmschleife-zuerst-Reihenfolge (engl. „innermost loop-first Order”) verarbeitet. Eine detaillierte Beschreibung von der Art und Weise, in welcher der Compiler 150 den intermediären Code verarbeitet, folgt.
Die 2A–2D zeigen ein Flussdiagramm von Verfahrensschritten 200 zum Reduzieren von Vorzeichenerweiterungsinstruktionen, die ein Programmschleifen eines 64-Bit-Computerprogramms enthalten sind, gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Zusammenhang mit dem System von 1 beschrieben werden, werden durchschnittliche Fachleute verstehen, dass jedes System, das zum Durchführen der Verfahrensschritte, in jeder beliebigen Reihenfolge, konfiguriert ist, innerhalb des Umfangs der Erfindung ist.
Wie es in 2A gezeigt ist, beginnt das Verfahren 200 bei Schritt 202, in welchem der Compiler 150 intermediären Code eines Computerprogramms erhält, der mindestens eine Programmschleife enthält. Bei Schritt 204 initialisiert der Compiler 150 eine Abbildung (engl. „map”) mit einem (Schlüssel)→(Wert)-Format von (v1, <Typ>)→(v2), wobei v2 der vorzeichenerweiterte Wert von v1 ist und ein Typ v2 <Typ> ist. Beispielhafte „Typen” enthalten int32 (das heißt, 32-Bit Ganzzahlen) und int64 (das heißt, 64-Bit Ganzzahlen). Falls zum Beispiel v1 eine 32-Bit Ganzzahl ist, dann bedeutet (v1, int64)→(v2), dass v2 eine 64-Bit Ganzzahl-Darstellung von dem 32-Bit Ganzzahlwert von v1 ist. v2 ist äquivalent zu Vorzeichenerweiterung von v1 und kann anstelle einer solchen Vorzeichenerweiterung verwendet werden.
Bei Schritt 206 setzt der Compiler 150 eine jetzige Programmschleife zum Zeigen auf die erste Programmschleife in einer innerste-Programmschleife-zuerst-Reihenfolge. In einem Beispiel ist der intermediäre Code wie folgt:
Erläuterung: Im obigen Beispiel ist unter ”preheader” Pre-Header zu verstehen, unter ”loop body” Programmschleifenkörper zu verstehen und unter „if (cond)” wenn (Bedingung) zu verstehen.
Die erste Programmschleife des intermediären Codes ist im obigen Beispiel der „Körper” der Programmschleife und enthält sechs separate Instruktionen. Folglich zeigt die jetzige Programmschleife nach dem ersten Durchlauf des Schrittes 206 auf die „Körper”-Programmschleife. Bei Schritt 208 stellt der Compiler 150 fest, ob die jetzige Programmschleife mindestens eine Vorzeichenerweiterungsinstruktion (SEI) von der Form „t1 = sxt(t2)” enthält. Die intermediäre Instruktion „temp1.i64 = sxt(i1.i32)” in dem obigen Beispiel erfüllt die Kriterien des Schrittes 208. In diesem Beispiel verhindert die Instruktion „temp1.i64 = sxt(i1.i32)” eine Aufwandsreduktion (engl. „strength reduction”) des Ausdrucks „4*tmp1.i64”. Es ist folglich das Ziel des Compilers 150, den intermediären Code, der beim Schritt 202 erhalten wurde, so zu modifizieren, dass die Vorzeichenerweiterung von „i1.i32” durch Befördern von i1.32 zu einem 64-Bit Wert eliminiert wird. Falls der Compiler 150 beim Schritt 208 feststellt, dass die jetzige Programmschleife mindestens eine SEI von der Form „t1 = sxt(t2)” enthält, dann geht das Verfahren 200 weiter zum Schritt 210. Anderenfalls geht das Verfahren 200 weiter zum Schritt 218 von 2B, welcher, wie es unter dargelegt wird, ein Feststellen enthält, ob zusätzliche Programmschleifen, die Vorzeichenerweiterungsinstruktionen enthalten mögen, in dem intermediären Code enthalten sind.
Bei Schritt 210 setzt der Compiler 150 eine jetzige SEI zum Zeigen auf eine erste SEI der ersten Programmschleife. Fortsetzend mit dem obigen Beispiel würde die jetzige SEI auf die SEI „temp1.i64 = sxt(i1.i32)” zeigen nach dem ersten Durchlauf des Schrittes 210. Bei Schritt 212 stellt der Compiler 150 fest, ob die jetzige SEI (das heißt, „temp1.i64 = sxt(i1.i32)”) von einer Induktionsvariable der jetzigen Programmschleife angewendet wird und dass alle Anwendungen von t1 (das heißt, „temp1.i64”) der jetzigen SEI affin sind. Der Code „4*temp1.i64” in dem obigen Beispiel ist zum Beispiel eine affine Anwendung. Falls das Ergebnis des Schrittes 212 wahr (engl. „true”) ist, dann ist die jetzige SEI eine Kandidatin eliminiert zu werden und das Verfahren 200 geht weiter zu Schritt 222, der unten beschrieben wird. Anderenfalls geht das Verfahren 200 weiter zu Schritt 214, der auch unten beschrieben wird.
Bei Schritt 222 stellt der Compiler 150 fest, ob der Operand t2 der jetzigen SEI ein Blatt (engl. „leaf”) in der jetzigen Programmschleife ist. In einer Ausführungsform wird t2 als ein Blatt der jetzigen Programmschleife erachtet, falls t2 außerhalb der jetzigen Programmschleife definiert ist oder falls t2 weder ein nicht überlaufender binärer Operator noch ein Phi-Operator noch ein Umwandlungsoperator (engl. „convert operator”) (zum Beispiel Vorzeichenerweiterung oder Nullerweiterung (engl. „zero-extension”)) ist. Falls der Compiler 150 im Schritt 222 feststellt, dass t2 der jetzigen SEI ein Blatt der jetzigen Programmschleife ist, dann geht das Verfahren 200 zurück zum Schritt 214, der unten beschrieben wird. Anderenfalls geht das Verfahren 200 weiter zu Schritt 224, bei dem der Compiler 150 die jetzige SEI auf einen Stack von SEIs hinauf schiebt (engl. „pushes”). Dieser Stack stellt eine Liste von Vorzeichenerweiterungsinstruktionen dar, die verarbeitet werden sollen, und ermöglicht, dass der Compiler 150 SEIs auf den Stack von SEIs hinauf schiebt und SEIs von dem Stapel von SEIs herausnimmt (engl. „pop SEIs off of the stack of SEIs”). Fortsetzend mit dem obigen Beispiel wird der Stack {„tmp1.i64=sxt(i1.i32)”} und die Abbildung ist {}.
Bei Schritt 226 stellt der Compiler 150 fest, ob der Stack von SEIs leer ist. Falls der Compiler 150 beim Schritt 150 feststellt, dass der Stack von SEIs leer ist, dann geht das Verfahren 200 weiter zum Schritt 214, der unten beschrieben wird. Anderenfalls geht das Verfahren 200 weiter zu Schritt 228, in welchem der Compiler 150 eine temporäre SEI von dem Stack von SEIs herausnimmt.
Bei Schritt 230 stellt der Compiler 150 fest, ob die temporäre SEI ein Blatt der jetzigen Programmschleife ist. Falls der Compiler 150 beim Schritt 230 feststellt, dass t2 der temporären SEI ein Blatt der jetzigen Programmschleife ist, dann geht das Verfahren 200 weiter zu Schritt 232 von 2C, der unten beschrieben wird. Anderenfalls geht das Verfahren 200 zurück zum Schritt 226, der oben beschrieben wurde. Fortsetzend mit dem obigen Beispiel ist „i1.i32” in der Programmschleife definiert, so „i1.i32” wird nicht als ein Blatt erachtet.
Beim Schritt 232 stellt der Compiler 150 fest, ob 1) die temporäre SEI von der Form „t1 = sxt(t2)” ist und ob 2) t2 von der temporären SEI von der Form „t2 = op x y” ist. Falls der Compiler 150 beim Schritt 232 feststellt, dass 1) die temporäre SEI von der Form „t1 = sxt(t2)” ist, und dass 2) t2 von der temporären SEI von der Form „t2 = op x y” ist, dann geht das Verfahren 200 weiter zu Schritt 234. Anderenfalls geht das Verfahren 200 zurück zum Schritt 226 von 2B, der oben beschrieben wurde.
Beim Schritt 234 stellt der Compiler 150 fest, ob ein Wert für den Schlüssel (x, <Typ von t1 von der temporären SEI>) in der Abbildung existiert. Fortsetzend mit dem obigen Beispiel ist t2 „i1.i32 = phi(i0.i32:preheader, i2.i32:loop body)” und die Abbildung ist leer. Falls der Compiler 150 beim Schritt 234 feststellt, dass ein Wert für den Schlüssel (x, <Typ von t1 von der temporären SEI>) in der Abbildung existiert, dann geht das Verfahren 200 weiter zu Schritt 238, der unten beschrieben wird. Anderenfalls geht das Verfahren 200 weiter zu Schritt 236, bei welchem der Compiler 150 1) die SEI „x' = sxt(x)” auf den Stack von SEIs hinauf schiebt und 2) x' in den intermediären Code hinein fügt vor der Verwendung von x in t2 von der temporären SEI.
Beim Schritt 238 stellt der Compiler 150 fest, ob ein Wert in der Abbildung für den Schlüssel (y, <Typ von t1 von der temporären SEI>) existiert. Falls der Compiler 150 beim Schritt 238 feststellt, dass ein Wert in der Abbildung für den Schlüssel (y, <Typ von t1 von der temporären SEI>) existiert, dann geht das Verfahren 200 weiter zu Schritt 242, der unten beschrieben wird. Anderenfalls geht das Verfahren 200 weiter zu Schritt 240, in welchem der Compiler 150 1) die SEI „y' = sxt(y)” auf den Stack von SEIs hinauf schiebt und 2) y' in der intermediären Code hinein fügt vor der Verwendung von y in t2 von der temporären SEI. Die Ausführung des Schritts 240 umfasst insbesondere, dass eine Vorzeichenerweiterung in den Pre-Header der jetzigen Programmschleife hinein gefügt wird.
Das Verfahren 200 geht folglich weiter zu Schritt 242, bei welchem der Compiler 150 die SEI „t2' = op x' y'” nach t2 der temporären SEI in die intermediäre Code hinein einfügt und die Abbildung derart aktualisiert, dass sie das Mapping (t2, <Typ(t2')>) → t2' enthält. Das Verfahren geht dann weiter zu Schritt 244 der 2D. Fortsetzend mit dem obigen Beispiel enthält der Stack von SEIs {„i0'.i64 = sxt(i0.i32)”, „i2'.i64 = sxt(i2.i32)”} und die Abbildung enthält {<i1.i64> → i1'}. Der intermediäre Code wird des Weiteren:
so dass alle Verwendungen von ”tmp1.i64” durch ”i1'.i64” ersetzt werden und „tmp1.i64 = sxt(i1.i32)” gelöscht wird. Wenn neue Vorzeichenerweiterungsinstruktionen vor Verwendungen eingefügt werden, werden Phi-Instruktionen insbesondere speziell behandelt. Eine Verwendung in Phi, wie zum Beispiel „i0.i32:preheader”, wird als eine Verwendung der letzten Instruktion auf einem Pre-Header-Block der jetzigen Programmschleife behandelt. Dies ist eine Standardinterpretation von Verwendungen, die in Phi-Instruktion in SSA-Darstellung (engl. „SSA representation”) vorkommen.
Bei Schritt 244 mappt der Compiler 150 den Schlüssel (t2, <Typ von t1 von der temporären SEI>) zu dem Wert von t2' in der Abbildung. Bei Schritt 246 ersetzt der Compiler 150, in der jetzigen Programmschleife, alle Vorkommnisse von t1 durch t2'. Bei Schritt 248 entfernt der Compiler 150 die temporäre SEI aus der jetzigen Programmschleife. Das Verfahren 200 returniert dann zum Schritt 226 der 2B, in welchem die Verfahrensschritte 228–248 wiederholt werden bis der Stack von SEIs leer ist. Fortsetzend das obige Beispiel ist die SEI „i0'.i64 = sxt(i0.i32)” ein Blatt, da i0.i32 außerhalb der Programmschleife definiert ist, und wird folglich von dem Verfahren 200 außer Acht gelassen. Alternativ ist die SEI „i2'.i64 = sxt(i2.i32)” für die Operation des Schritts 240 geeignet. Gemäß der hierin beschriebenen Technik würde das Modifizieren der SEI „i2'.i64 = sxt(i2.i32)” beinhalten, dass der Compiler 150 eine SEI „i3.i64 = i1'.i64 + 1” nach der SEI „i2.i32 = i1.i32 + 1” einfügen, alle Vorkommnisse von „i2'.i64” durch „i3'.i64” ersetzen und die SEI „i2'.i64 = sxt(i2.i32)” löschen wurde. Folglich ist der intermediäre Code nach Elimination aller Vorzeichenerweiterungen wie folgt:
Als ein Ergebnis werden die 32-Bit-Berechnungen von {i0, i1, i2} zu 64-Bit-Berechnungen von {i0', i1', i3') befördert. Dies erlaubt vorteilhafterweise, dass nachfolgende Optimierungsdurchläufe von dem Compiler 150 durchgeführt werden, wie zum Beispiel Aufwandsreduktion und Eliminierung von Induktionsvariablen, um die redundanten 32-Bit-Berechnungen zu eliminieren.
Jetzt mit Rückbezug auf den Schritt 208, falls der Compiler 150 feststellt, dass die jetzige Programmschleife nicht mindestens eine SEI von der Form „t1 = sxt(t2)” enthält, dann geht das Verfahren 200 weiter zum Schritt 218 der 2B, der oben beschrieben wurde.
Jetzt mit Rückbezug auf den Schritt 212, falls der Compiler 150 feststellt, dass „t2” von der jetzigen SEI keine affine Funktion einer Induktionsvariable der jetzigen Programmschleife ist, dann geht das Verfahren weiter zu Schritt 214, bei dem der Compiler 150 feststellt, ob zusätzliche SEIs in der jetzigen Programmschleife enthalten sind. Falls der Compiler 150 beim Schritt 214 feststellt, dass zusätzliche SEIs in der jetzigen Programmschleife enthalten sind, dann geht das Verfahren 200 weiter zu Schritt 216, der unten beschrieben wird. Anderenfalls geht das Verfahren 200 weiter zum Schritt 218 der 2B, der oben beschrieben wurde.
Beim Schritt 216 setzt der Compiler 150 die jetzige SEI zum Zeigen auf eine nächste SEI der jetzigen Programmschleife. Der Compiler 150 ist, wie es früher hierin erwähnt wurde, dazu konfiguriert, die Programmschleifen in einer innerste-Programmschleife-zuerst-Reihenfolge zu verarbeiten, was erlaubt, dass Vorzeichenerweiterungen, die in einem Programmschleifen-Pre-Header eingefügt worden sind, eliminiert werden, wenn die einschließende (engl. „enclosing”) Programmschleife anschließend verarbeitet wird. Beim Schritt 218 stellt der Compiler 150 fest, ob zusätzliche Programmschleifen in dem intermediären Code enthalten sind. Falls der Compiler 150 beim Schritt 218 feststellt, dass zusätzliche Programmschleifen in dem intermediären Code enthalten sind, dann geht das Verfahren 200 weiter zu Schritt 220, der unten beschrieben wird. Anderenfalls endet das Verfahren 200, da jede Programmschleife, die in dem intermediären Code enthalten ist, von dem Compiler 150 gemäß den hierein beschriebenen Techniken untersucht worden ist.
Beim Schritt 220 setzt der Compiler 150 die jetzige Programmschleife zu einer nächsten Programmschleife, die in dem intermediären Code enthalten ist. Das Verfahren 200 geht dann zurück zum Schritt 208, wonach die nachfolgenden Schritte 210–248 gemäß der obigen Beschreibung durchgeführt werden.
Zusammengefasst legen Ausführungsbeispiele der Erfindung eine Technik zum Reduzieren von SEIs dar, die in Programmschleifen eines Computerprogramms enthalten sind. Der Compiler 150 erhält intermediären Code des Computerprogramms, wobei der intermediäre Code mindestens eine SEI enthält, die in einer Programmschleifenstruktur enthalten ist. Der Compiler 150 stellt gemäß dem oben beschriebenen Verfahren 200 fest, dass die mindestens eine SEI dazu geeignet ist, aus der Programmschleifenstruktur heraus bewegt zu werden, fügt eine zusätzliche SEI in einen Pre-Header von der Programmschleifenstruktur hinein und eliminiert dann die SEI in der Programmschleife, was der Code für zusätzliche Aufwandsreduktionsmöglichkeiten geeignet macht.
Ein Vorteil von den hierin offenbarten Techniken ist, dass kompilierte intermediäre Instruktionen von dem Compiler 150 automatisch auf zusätzliche Optimierungsmöglichkeiten geprüft werden. In dieser Weise mag die gesamte Anzahl von Instruktionen reduziert werden, aus denen das Computerprogramm besteht oder die das Computerprogramm fordert, dass ein Prozessor beim Ausführen des Computerprogramms durchführt, wobei die gesamte Ausführungseffizienz des Computerprogramm erhöht wird. Des Weiteren führen weniger oder effizientere Instruktionen dazu, dass weniger Taktzyklen benötigt werden, um das Computerprogramm auszuführen, was mit einer Einsparung der Gesamtenergieverbrauch direkt korreliert ist.
Eine Ausführungsform der Erfindung mag als ein Computerprogrammprodukt zur Verwendung mit einem Computersystem implementiert sein. Das Programm bzw. die Programme des Programmprodukts definiert bzw. definieren Funktionen der Ausführungsformen (einschließlich der hierin beschriebenen Verfahren) und kann bzw. können auf einer Vielfalt von computerlesbaren Speichermedien enthalten werden. Beispielhafte computerlesbare Speichermedien umfassen, sind aber nicht darauf begrenzt: (i) nicht-schreibbare Speichermedien (zum Beispiel schreibgeschützte („read-only”) Speichervorrichtungen in einem Computer, wie zum Beispiel CD-ROM-(„compact disc read only memory”)-Discs, die mittels eines CD-ROM-Laufwerks lesbar sind, Flash-Speicher, ROM-(„read only memory”)-Chips oder jede andere Art von nichtflüchtigem Festkörper-Halbleiterspeicher („solid-state non-volatile semiconductor memory”)), auf welchen Informationen permanent gespeichert werden; und (ii) schreibbare Speichermedien (zum Beispiel Floppy-Disks in einem Diskettenlaufwerk oder Festplattenlaufwerk oder jeder Art Festkörper-Halbleiterspeicher mit wahlfreiem Zugriff („solid-state random-access semiconductor memory”)), auf welchem veränderbare Informationen gespeichert sind.
Die Erfindung ist mit Bezug auf spezifische Ausführungsformen oben beschrieben worden. Durchschnittsfachleute werden aber verstehen, dass verschiedene Modifikationen und Änderungen davon gemacht werden mögen, ohne von dem breiteren Geist und Umfang der Erfindung abzuweichen, wie diese in den angehängten Patentansprüchen dargestellt ist. Die vorhergehende Beschreibung und vorhergehenden Zeichnungen sind folglich eher in einer illustrativen wie in einer restriktiven Bedeutung zu beachten.
Folglich ist der Umfang der Ausführungsformen der vorliegenden Erfindung in den nachfolgenden Patentansprüchen dargelegt.

Claims

Ein Verfahren zum Reduzieren von Vorzeichenerweiterungsinstruktionen (SEIs), die in einem Computerprogramm enthalten sind, das Verfahren aufweisend: Erhalten eines intermediären Codes, der mit dem Computerprogramm assoziiert ist und eine erste SEI enthält, die in einer Programmschleifenstruktur innerhalb des Computerprogramms enthalten ist; Feststellen, dass die erste SEI dazu geeignet ist, aus der Programmschleifenstruktur heraus bewegt zu werden; Einfügen einer zweiten SEI in einen Pre-Header der Programmschleife hinein, wobei die zweite SEI, wenn sie von einem Prozessor ausgeführt wird, einen ursprünglichen Wert, auf den die erste SEI zielt, von einem kleineren Typ zu einem größeren Typ befördert; und Ersetzen der ersten SEI durch eine oder mehrere intermediäre Instruktionen, die für zusätzliche Compiler-Optimierungen geeignet sind.
Das Verfahren gemäß Anspruch 1, wobei ein Operand, der mit der ersten SEI assoziiert ist, 32-Bits enthält, und wobei die erste SEI, wenn sie von einem Prozessor ausgeführt wird, den Operanden in 64-Bits umwandelt, aber das Vorzeichen oder den Wert, die mit dem Operanden assoziiert sind, nicht ändert.
Das Verfahren gemäß Anspruch 2, wobei die erste SEI dazu geeignet ist, aus der Programmschleifenstruktur heraus bewegt zu werden, wenn der Operand, der mit der ersten SEI assoziiert ist, eine affine Funktion von einer mit der Programmschleifenstruktur assoziierten Induktionsvariable aufweist.
Das Verfahren gemäß Anspruch 3, wobei der Operand das Format „Operand = C1*i + C2” hat, wobei der Wert von „i” während des Ausführens der Programmschleifenstruktur modifiziert wird, und wobei C1 und C2 konstante Werte sind.
Das Verfahren gemäß Anspruch 1, wobei die zweite SEI, wenn sie von dem Prozessor ausgeführt wird, bewirkt, dass der Prozessor einen vorzeichenerweiterten Wert von einem mit der zweiten SEI assoziierten Operanden in einer Variable speichert.
Das Verfahren gemäß Anspruch 5, wobei die eine oder mehreren intermediären Instruktionen Bezug auf die Variable nimmt, um den vorzeichenerweiterten Wert des mit der zweiten SEI assoziierten Operanden zu erlangen.
Das Verfahren gemäß Anspruch 1, ferner aufweisend: Feststellen, dass der intermediäre Code, der mit dem Computerprogramm assoziiert ist, eine dritte SEI enthält, die in der Programmschleifenstruktur enthalten ist; Feststellen, dass ein Operand, der mit der dritten SEI assoziiert ist, einen konstanten Wert aufweist; und Ersetzen der dritten SEI durch einen konstanten Wert, der eine Anzahl von Bits hat, die von der dritten SEI definiert ist.
Das Verfahren gemäß Anspruch 1, ferner aufweisend: Feststellen, dass der intermediäre Code, der mit dem Computerprogramm assoziiert ist, eine vierte SEI enthält, die in der Programmschleifenstruktur enthalten ist; Feststellen, dass ein Operand, der mit der vierten SEI assoziiert ist, eine Anzahl von Bits hat, die von der vierten SEI definiert ist; und Ersetzen der vierten SEI durch den Operanden, der mit der vierten SEI assoziiert ist, wobei der intermediäre Code, wenn er von dem Prozessor ausgeführt wird, den Operanden der vierten SEI nicht vorzeichenerweitert.
Verfahren gemäß Anspruch 1, wobei die intermediären Instruktionen, die in dem Pre-Header der Programmschleifenstruktur enthalten sind, nur einmal vor dem Ausführen der intermediären Instruktionen, die in der Programmschleifenstruktur enthalten sind, ausgeführt werden.
Ein System zum Reduzieren von Vorzeichenerweiterungsinstruktionen (SEIs), die in einem Computerprogramm enthalten sind, das System aufweisend: einen Prozessor, der konfiguriert ist zum: Erhalten eines intermediären Codes, der mit dem Computerprogramm assoziiert ist und eine erste SEI enthält, die in einer Programmschleifenstruktur innerhalb des Computerprogramms enthalten ist; Feststellen, dass die erste SEI dazu geeignet ist, aus der Programmschleifenstruktur heraus bewegt zu werden; Einfügen einer zweiten SEI in einen Pre-Header der Programmschleife hinein, wobei die zweite SEI, wenn sie von einem Prozessor ausgeführt wird, einen ursprünglichen Wert, auf den die erste SEI zielt, von einem kleineren Typ zu einem größeren Typ befördert; und Ersetzen der ersten SEI durch eine oder mehrere intermediäre Instruktionen, die für zusätzliche Compiler-Optimierungen geeignet sind.