GNU Compiler Collection

1997 spaltete sich das Projekt Experimental/Enhanced GNU Compiler System (EGCS, engl. für experimentelles/verbessertes GNU-Compilersystem) von GCC ab, und wurde 1999 mit diesem wieder vereinigt.[9]

GCC 1.x hatte 1991 eine gewisse Stabilität erreicht, jedoch verhinderten architekturbedingte Einschränkungen viele Verbesserungen, sodass die Free Software Foundation (FSF) damit begann, GCC 2.x zu entwickeln. Mitte der 1990er kontrollierte die FSF jedoch sehr genau, was zu GCC 2.x hinzugefügt werden durfte und was nicht, sodass GCC als Beispiel für das „Cathedral“-Entwicklungsmodell Verwendung fand, das Eric S. Raymond in seinem Buch Die Kathedrale und der Basar beschreibt.

Da GCC freie Software ist, ist es Programmierern, die in eine andere Richtung arbeiten wollten, erlaubt, eigene Abspaltungen zu entwickeln. Viele Abspaltungen erwiesen sich jedoch als ineffizient und unübersichtlich. Dass ihre Arbeiten vom offiziellen GCC-Projekt oft nicht, oder nur unter Schwierigkeiten akzeptiert wurden, frustrierte viele Entwickler.

Daher gründete eine Gruppe von Entwicklern 1997 EGCS, um mehrere experimentelle Abspaltungen in einem einzigen Projekt zu vereinen. Dazu gehörten g77 (Fortran), PGCC (Pentium-optimierter GCC), das Einpflegen vieler Verbesserungen an C++, sowie Compiler-Versionen für weitere Prozessor-Architekturen und Betriebssysteme.

Die Entwicklung von EGCS erwies sich als schneller, lebhafter und insgesamt besser als die des GCC-Projektes, sodass die FSF 1999 offiziell die Weiterentwicklung von GCC 2.x einstellte und stattdessen EGCS als offizielle GCC-Version übernahm. Die EGCS-Entwickler wurden zu Projektverantwortlichen (engl. maintainer) des GCC. Von da an wurde das Projekt explizit nach dem „Basar“-Modell entwickelt, nicht mehr nach dem „Cathedral“-Modell. Mit der Veröffentlichung von GCC 2.95 im Juli 1999 waren beide Projekte wiedervereinigt.

Frontends müssen Bäume produzieren, die vom Backend verarbeitet werden können. Wie sie dies erreichen, bleibt ihnen überlassen. Einige Parser benutzen Yacc-ähnliche Grammatiken, andere verwenden handgeschriebene, rekursive Parser.

Bis vor kurzem war die Baumrepräsentation des Programms nicht völlig vom Zielprozessor unabhängig. Die Bedeutung eines Baums konnte für unterschiedliche Sprachfrontends unterschiedlich sein, und Frontends konnten ihren eigenen Baumcode zur Verfügung stellen.

Mit dem Tree-SSA-Projekt, das in die Version GCC 4.0 integriert wurde, wurden zwei neue Formen von sprachunabhängigen Bäumen eingeführt. Diese neuen Baumformate wurden GENERIC und GIMPLE getauft. Parsing wird nun durchgeführt, indem ein temporärer sprachabhängiger Baum nach GENERIC konvertiert wird. Der sogenannte „Gimplifier“ überführt diese komplexe Form in die SSA-basierte GIMPLE-Form, von der ausgehend eine Reihe neuer sprach- und architekturunabhängiger Optimierungen durchgeführt werden kann.

Optimierung an Bäumen passt eigentlich nicht in das Schema von „Frontend“ und „Backend“, da sie nicht sprachabhängig sind und kein Parsen beinhalten. Die GCC-Entwickler haben diesem Teil des Compilers daher den Namen „Middleend“ gegeben. Zu den gegenwärtig am SSA-Baum durchgeführten Optimierungen gehören Dead code elimination, Partial Redundancy Elimination, Global Value Numbering, Sparse Conditional Constant Propagation, Scalar replacement of Aggregates und Array-basierende Optimierungen, wie automatische Vektorisierung.[14]

Das Verhalten des GCC-Backends wird teilweise durch Präprozessor-Makros und architekturspezifische Funktionen bestimmt, mit denen zum Beispiel die Endianness, Wortgröße, und Aufrufkonventionen definiert und die Registerstruktur der Zielmaschine beschrieben werden. Unter Verwendung der Maschinenbeschreibung, einer Lisp-ähnlichen Beschreibungssprache, wandelt GCC die interne Baumstruktur in die RTL-Darstellung um. Obwohl diese dem Namen nach prozessorunabhängig ist, ist die Sequenz an abstrakten Instruktionen daher bereits an das Ziel angepasst.

Die Art und Anzahl der vom GCC an der RTL durchgeführten Optimierungen werden mit jeder Compiler-Version weiterentwickelt. Zu ihnen gehören etwa (global) common subexpression elimination, verschiedene Schleifen- und Sprungoptimierungen (englisch if-conversion, branch probability estimation, sibling calls, constant propagation, ...) sowie der combine-pass, in dem mehrere Instruktionen zu einer einzigen kombiniert werden können.

Seit der Einführung von globalen SSA-basierten Optimierungen an GIMPLE-Bäumen haben die RTL-Optimierungen leicht an Bedeutung verloren, da in der RTL-Repräsentation des Programms weit weniger der für viele Optimierungen wichtigen High-Level-Informationen enthalten sind. Allerdings sind auch maschinenabhängige Optimierungen sehr wichtig, da für viele Optimierungen Informationen über die Maschine vorliegen müssen, etwa darüber, welche Instruktionen eine Maschine kennt, wie teuer diese sind und wie die Pipeline der Zielarchitektur beschaffen ist.

In der „Reload“-Phase wird die prinzipiell unbeschränkte Anzahl an abstrakten Pseudo-Registern durch die begrenzte Anzahl an echten Maschinenregistern ersetzt, wobei hier unter Umständen neue Instruktionen in den Code eingefügt werden müssen, um zum Beispiel Pseudo-Register auf dem Stack der Funktion zwischenzuspeichern. Diese Registerzuteilung ist recht kompliziert, da die verschiedenen Eigenheiten der jeweiligen Zielarchitektur besonders berücksichtigt werden müssen.

In der letzten Phase werden Optimierungen durchgeführt, wie peephole optimization und delay slot scheduling, bevor die recht maschinennahe Ausprägung der RTL auf Assemblercode abgebildet wird, indem die Namen von Registern und Adressen in Zeichenketten umgesetzt werden, welche die Instruktionen spezifizieren.