Kennzeichnend für LLVM ist unter anderem, dass sämtliche Zeitphasen eines Programmablaufs inklusive des Leerlaufprozesses[12] zur Optimierung herangezogen werden können.
Die Entwicklung von LLVM begann im Jahr 2000 unter der Leitung von Chris Lattner und Vikram Adve an der Universität von Illinois. Das Projekt wurde ursprünglich als Forschungsarbeit zur Untersuchung dynamischer Kompilierung und Optimierungen entwickelt. Heute beheimatet es eine Vielzahl an Unterprojekten und Erweiterungen aus der aktuellen Compilerforschung und -entwicklung.[1][13][14]
Name
„LLVM“ ist heute der volle Name des Projekts und kein Akronym.[1] LLVM wurde früher als „Low Level Virtual Machine“ übersetzt, was für Verwirrung sorgt. Mit der Zeit wurde LLVM ein Rahmenprojekt, in dem verschiedene Compiler- und Low-Level-Techniken enthalten sind. Inzwischen ist LLVM die Marke für das eigentliche Projekt, die LLVM-Zwischensprache (LLVM-IR), den LLVM-Debugger (LLDB), die LLVM-Standard-C++-Bibliothek (libc++) etc.
Arbeitsweise
Herkömmliche Compilersysteme führen Optimierungsvorgänge meist beim Kompilieren durch und verbinden die kompilierten Module dann miteinander. Dieser zweite Vorgang wird Binden oder auch Linken genannt und bietet ebenfalls Optimierungsmöglichkeiten, die bisher wenig genutzt wurden, da der Linker nur die einzelnen Module sieht und nicht das gesamte Programm. Hier setzt LLVM an, indem es einen nach Vorbild der RISC-Befehlssätze gestalteten virtuellen Bytecode erstellt, der während des Linkens mit dem eigenen Linker lld[15] noch einmal optimiert werden kann.[11][16]
Ein Teil der Architektur von LLVM basiert auf einer virtuellen Maschine, die einen Prozessor virtualisiert. Ein Prozessor kann dabei nicht nur ein Hauptprozessor (CPU) sein, sondern auch ein Grafikprozessor (GPU). Die virtuelle Maschine ist in der Lage, die intern generierte Sprache (sog. intermediate language) des Compilers (LLVM Assembly Language)[17] während der Ausführung für den Prozessor des aktuellen Systems zu übersetzen. Kennzeichnend ist hierbei, dass sie hocheffizient ist, was die Übersetzung auch Just-in-Time (also auf Anforderung, bei Bedarf) ermöglicht, und diese mit einer Größe von nur 20 kB extrem kompakt ist, wodurch die Ausführung auch auf einfachen Prozessoren, älteren Grafikprozessoren (GPUs) oder Embedded-CPUs, und insbesondere sogar direkt im Cache möglich ist.
Über ein flexibles LLVM-Backend ist es möglich, eine fast beliebige Vielzahl unterschiedlichster Prozessor-Architekturen zu unterstützen.[18]
Die LLVM-Bibliotheken können von Compilerprojekten, denen das Schreiben eines eigenen Codegenerators zu aufwendig wäre, eingesetzt werden, um auf einfache Weise Maschinencode (Bitcode, Microcode) zu erzeugen. Zum Beispiel muss das Compiler-Frontend Clang, welches Bestandteil von LLVM ist, nur den C- bzw. C++-Code parsen und in die LLVM-Zwischensprache (LLVM Intermediate Representation, LLVM IR) übersetzen. Das Erzeugen von effizientem Maschinencode kann dem LLVM-Backend überlassen werden. Bei diesem Beispiel kommt die virtuelle Maschine nicht zum Einsatz, da LLVM hier nur als Compiler-Backend für die jeweilige Architektur (x86, PowerPC, IA64, …) agiert.[19]
Mit LLVM lassen sich virtuelle Maschinen für Sprachen wie Java, plattformspezifische Codegeneratoren und von Sprache und Plattform unabhängige Optimierer erstellen. Die LLVM-Zwischenschicht (IR) liegt zwischen sprachspezifischen Modulen und den jeweiligen Codegeneratoren und kann als eine Art plattformunabhängige Assemblersprache betrachtet werden. LLVM unterstützt weiterhin dynamische, interprozedurale Optimierung sowie statische Ahead-of-time- und Just-in-time-Kompilierung.[18] Ein Beispiel für LLVM-IR:
; String-Konstante als globale Konstante deklarieren@.str=privateunnamed_addrconstant[13xi8]c"hello world\0A\00"; Externe Deklaration der `puts()`-Funktion (enthalten in libc)declarei32@puts(i8*nocapture)nounwind; Definition der `main()`-Funktiondefinei32@main(){; i32()*; Konvertiere [13 x i8]* zu i8 *... (Pointer auf i8-Elemente)%cast210=getelementptr[13xi8]*@.str,i640,i640; Rufe `puts()`-Funktion auf, um Text auszugebencalli32@puts(i8*%cast210)reti320}; Metadaten!1=metadata!{i3242}!foo=!{!1,null}
Clang ist ein für LLVM entwickeltes Frontend, das für C-ähnliche Sprachen optimiert ist. Es ermöglicht gegenüber dem GCC-Oberbau vor allem schnellere Übersetzungsläufe mit geringerem Speicherverbrauch und als Ergebnis oft kleinere ausführbare Dateien. Zudem verfügt es über umfangreichere und genauere statische Analysemethoden, die dem Entwickler z. B. die Fehlersuche erleichtern. Die Unterstützung der Programmiersprache C++ gilt ab Version 2.7 als stabil.[20]
Seit September 2009 gilt Clang offiziell als stabil und produktiv verwendbar. Ab LLVM Version 2.6 befindet es sich als fester Bestandteil im LLVM-Compiler-Paket.[21] Clang lässt sich aber auch ohne LLVM als rein statisches Codeanalyse- und Debug-Werkzeug, zum Beispiel beim Einsatz mit anderen Compilern, verwenden.[22] Clang ist seit 2013 zur statischen Code-Analyse in die Entwicklungsumgebung Xcode von Apple für die Programmiersprachen C, Objective-C und C++ integriert.
LLDB
LLDB ist ein auf Techniken des LLVM-Projektes aufbauender und für C-basierte Sprachen optimierter, modularer und hochdynamischer Debugger. Er soll besonders speichereffizient und zugleich extrem leistungsfähig und schnell sein. Er verfügt über eine Plug-In-Schnittstelle zum Beispiel für die Unterstützung anderer Programmiersprachen. Zudem lassen sich Aufgaben mit Hilfe von Python automatisieren. Zu den Zielsetzungen zählt eine umfassende Unterstützung für das Debuggen von Multithreading-Code.[23][24]
DragonEgg
Bei DragonEgg handelt es sich um ein LLVM-Plugin für die GNU Compiler Collection (ab Version 4.5).[25] Dieses ermöglicht es, LLVM optional als Compiler-Backend einer ungepatchten GCC-Installation zu nutzen. DragonEgg wurde zu Beginn der Entwicklung nur als „the gcc plugin“ bezeichnet. DragonEgg löst die bisher häufig verwendete LLVM-GCC-Mischkonfiguration ab.
vmkit
Hierbei handelt es sich um einen modifizierten Zweig (Fork) der LLVM-VM, welche die direkte Ausführung von Java- und CIL-Bytecode (.Net-Framework/Mono) ermöglicht. Der Compiler beziehungsweise Linker kann das hochkompakte vmkit (ca. 20 kB) vor den Java- oder CIL-Bytecode packen und ausführen, wodurch die Ausführung auf beliebigen Prozessorarchitekturen und auf Systemen ohne vorherige Installation von Java oder .NET möglich ist. Das Projekt wird allerdings derzeit nicht mehr offiziell unterstützt.[26]
KLEE
Mit KLEE kann man Programme unüberwacht und automatisch auf Programmfehler untersuchen lassen. Dabei wird das Programm Schritt für Schritt ausgeführt. Statt konkreter Werte werden Eingabe und Zwischenresultate symbolisch verwendet und jeweils gespeichert, welche Werte diese haben könnten. Dabei wird bei „gefährlichen Operationen“ (englisch: „dangerous operations“, zum Beispiel Divisionen oder Speicherzugriffe per Zeiger) geprüft, ob sie einen Fehler erzeugen könnten, zum Beispiel eine Division durch null oder einen Zugriff auf nicht reservierten Speicher. KLEE gibt dann aus, bei welcher Eingabe das Programm den Fehler erzeugt und welcher Pfad durch den Quellcode dabei genommen wird.[27]
Jedoch gibt es noch einige Einschränkungen. Das Frontend (llvm-gcc) ist noch nicht für jede Plattform lauffähig. Dies kann umgangen werden, indem die LLVM als Cross-Compiler dient. Hier sollten eventuelle Abhängigkeiten, zum Beispiel die Programmbibliothek, berücksichtigt werden.[18]
Geschichte
Das Projekt startete 2000 an der University of Illinois at Urbana–Champaign als Studienprojekt von Vikram Adve und Chris Lattner. Als die Firma Apple darauf aufmerksam wurde, stellte sie 2005 ein festes Entwicklerteam für die Weiterentwicklung von LLVM zusammen und stellte Chris Lattner als dessen Projektleiter an.[28] LLVM ist seit Juli 2008 Standardcompiler in Apples Entwicklungsumgebung Xcode.[29] Ab Version 2.6 vom Oktober 2009 ist das Compiler-Frontend Clang integraler Bestandteil von LLVM.[30][31]
Viele weitere Komponenten befinden sich derzeit in intensiver Entwicklung, unter anderem Frontends für Java-Bytecode, OpenCL, Microsofts CIL, Python, Lua, PHP, Ruby, Mono[32] und Adobe ActionScript.[14][33] Der LLVM-JIT-Compiler kann ungenutzte statische Zweige des Programms zur Laufzeit erkennen und anschließend entfernen. Dies optimiert Programme mit einem hohen Grad an Verzweigung. Aus diesem Grund nutzt Apple seit macOS 10.5[34] LLVM im OpenGL-Stack, um einerseits sich selten ändernde Verzweigungspfade zu verkürzen und andererseits Vertex-Shader optimieren zu lassen.
↑Chris Lattner: LLVM 2.6 Release! In: llvm-announce mailing list. 23. Oktober 2009, archiviert vom Original am 11. Januar 2012; abgerufen am 5. Dezember 2010 (englisch).
↑Hans-Joachim Baader: LLVM 2.6 freigegeben. In: Pro-Linux. 26. Oktober 2009, abgerufen am 5. Dezember 2010.
