Es lassen sich in dem Wesentlichen zwei Phasen unterscheiden: eine Analysephase, die den Quelltext analysiert und daraus einen Syntaxbaum erzeugt, sowie die Synthesephase, die daraus die Absichtprogramm erzeugt.

Die lexikalische Analyse zerteilt den eingelesenen Quelltext in zusammengehörende Token verschiedener Klassen, z.B. Schlüsselwörter, Bezeichner, Zahlen und Operatoren. Dieser Teil des Compilers heißt Scanner oder Lexer.

Ein Scanner benutzt gelegentlich einen separaten Screener, um Whitespace (Leerraum, also Leerzeichen, Zeilenenden, usw.) und Kommentare zu überspringen.

Die syntaktische Analyse überprüft, ob der eingelesene Quellcode formal richtig ist, d.h. der Syntax (Grammatik) der Quellsprache entspricht. Dabei wird die Eingabe in einen Syntaxbaum umgewandelt. Dieser Teil wird auch als Parser genannt.

Die semantische Analyse überprüft die statische Semantik, also "logische Rahmenbedingungen". Zu dem Beispiel muss eine Variable deklariert worden sein, bevor sie benutzt wird, und Zuweisungen müssen mit kompatibel (verträglich)

Die Synthesephase erzeugt aus dem in der Analysephase erstellten Baum den Programmcode der Absichtsprache.

Siehe Programmoptimierung.

Bei der Codegenerierung wird endgültig aus dem Syntaxbaum der Programmcode in der Absichtsprache erzeugt. Falls die Absichtsprache die Maschinensprache ist, kann das Ergebnis direkt ein ausführbares Programm sein oder eine so genannte Objektdatei , die durch das Linken mit der Laufzeitbibliothek und evtl. weiteren Objektdateien zu einer Bibliothek oder einem ausführbaren Programm führt.

Üblicherweise bietet ein Compiler Optionen für verschiedene Optimierungen mit dem Absicht, die Laufzeit oder den Speicherplatzbedarf deAbsichtprogramms zu verkleinern.

Die Optimierung erfolgt in Abhängigkeit von den Merkmalen der Hardware, z. B. wieviele und welche Register der Prozessor des Computers zur Verfügung stellt.

Einige Optimierungen führen dazu, dass der Compiler Programmkonstrukte in semantisch äquivalente, aber günstigere Konstrukte umwandelt, die keine Entsprechung in dem Quellcode haben. Eine Folge ist, dass es bei Aktivierung entsprechender Optimierungen kaum noch möglich ist, den Programmablauf mit einem interaktiven Debugger zu verfolgen.

Im Folgenden betrachten wir einige Optimierungsmöglichkeiten eines Compilers. Dabei handelt es sich naturgemäß ca. um Feinabstimmung an einem bestehenden Programm. "Optimierung" bedeutet auch nicht, dass das Programm danach in irgendeiner Weise optimal wäre, ca. besser. Es ist auch möglich, dass das Programm nachher "totoptimiert" ist, also die Optimierung über die Absicht soweit hinausgeschossen ist, dass das Programm effektiv langsamer ausgeführt wird. Viele Optimierungen moderner Compiler sind solche Abwägungen zwischen dem, was möglich ist, und dem, was sinnvoll ist. Die Grenze zwischen beiden ist meist nicht klar ersichtlich und muss durch Tests herausgefunden werden.

Es sollte nicht vergessen werden, dass das größte Optimierungspotenzial häufig darin besteht, den Algorithmus selbst zu verändern bzw. durch einen besseren zu ersetzen. Dieser Ablauf kann nicht automatisiert werden, sondern muss durch den Programmierer erfolgen.

Wenn man zu dem Beispiel in einer höheren Programmiersprache den Inhalt von 2 Variablen vertauscht, dann benötigt man eine Hilfsvariable:

Die Berechnung des Kreisumfangs mittels

         pi = 3.14
         u  = 2 * pi * r

kann ein Compiler bereits zu dem Ãœbersetzungszeitpunkt zu "u = 6.28 * r" auswerten. Dies spart die Multipliktion "2*pi" zur Laufzeit des erzeugten Programms. Diese Vorgehensweise wird als Konstantenfaltung (engl. "constant folding") genannt.

Wenn der Compiler erkennen kann, dass ein Teil des Programmes niemals durchlaufen wird, dann kann er diesen Teil bei der Ãœbersetzung weglassen.

  
Beispiel:  ...   ...
           100   goto 900
           200   k=3
           900   i=7
           ...   ...

Wenn in diesem Programm niemals ein GOTO auf das Label 200 erfolgt, dann kann auf die Anweisung "200 k=3" verzichtet werden.

Wird eine Variable nicht benötigt, dann wird sie auch nicht berechnet.

Beispiel:  subroutine test (a,b)
           b = 2 * a
           c = 3.14 * b
           return b

Hier wird die Variable c nicht benötigt: Sie steht nicht in der Parameterliste, wird in späteren Berechnungen nicht benutzt und wird auch nicht ausgegeben. Darum entfällt die Anweisung "c = 3.14 * b".

Insbesondere Schleifen versucht man zu optimieren, indem man z.B.:

• möglichst viele Variablen in Registern hält (z.B. die Schleifenvariable)
• Berechnungen innerhalb der Schleife, die in jedem Durchlauf dasselbe ergeben, ca. einmal berechnet
• die Schleife komplett auflöst (englisch loop unrolling), falls die Anzahl der Schleifendurchläufe konstant ist. Die Anweisungen innerhalb der Schleife werden dann sequentiell (hintereinander) ausgeführt ohne Verwendung einer Schleife.

Zusammenhängender Code - z. B. eine Schleife - sollte zur Laufzeit möglichst auf der gleichen "Seite" (zusammenhängend vom Betriebssystem verwalteter Speicherblock) in dem Hauptspeicher liegen. Dies kann man evtl. dadurch erreichen, dass man dem Programmcode geeignete Leeranweisungen ("NOPs" - No OPeration) hinzufügt. Dadurch wird der Programmcode zwar größer, aber wegen des reduzierten Pagings wird das Programm schneller ausgeführt.

• GNU Compiler Collection (GCC)
• Intel C Compiler (ICC)
• Microsoft Visual C++

oder auch viele andere, die zusammen mit IDEs ausgeliefert werden (Visual Basic, Delphi etc.)