LLVM — A Compilation Framework for Lifelong Program Analysis & Transformation

"LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation", Chris Lattner and Vikram Adve.
Proceedings of the 2004 International Symposium on Code Generation and Optimization (CGO'04), Palo Alto, California, Mar. 2004.

Transcript

1. LLVM — A Compilation Framework for Lifelong Program Analysis & Transformation Chris Lattner, Vikram Adve; Unversity of Illinois at Urbana-Champaign 2004 International Symposium on Code Generation and Optimization (CGO’04) [ Shao-Chung Chen ] VIPLab Group Meeting / Feb. 01, 2013 Dept. of Computer Science and Information E., NTNU
2. #include <stdio.h> int main (int argc, char* argv[]) { print("Hello World!\n"); return 0; }
3. gcc -o hello hello.c pre- processor (cpp) compiler (cc1) assembler (as) linker (ld) hello.i hello.s hello.o hello printf.o hello.c
4. LLVM
5. Low-Level Virtual Machine
6. What’s “Life-Long Program Optimization”? • multiple-stage of analysis & transformation • compile-time, link-time, install-time, run-time, idle-time • aggressive interprocedural optimizations • gather & exploit end-user profile information • optimize to the user’s hardware • constraints • cannot interfere with the build process • must support multiple source-languages • must integrate with legacy systems and compnents
7. 5 Key Goals/Capabilities • a persistent, rich code representation • for analysis & optimization throughout lifetime • offline native code generation • generate high-quality code statically • profiling & optimization in the field • adapt to the end-user’s usage patterns (profile info) • language independence • no runtime, object model, or exception semantics • uniform whole-program optimization • optimization across language and runtime
8. Previous Approaches Persistent Rich Code Offline Codegen End-User Profiling Transparent Runtime Uniform Whole- Program Source-Level Compilers ✔ ✔ Source-Level Link-time IPOs through link-time ✔ ✔ Machine Code Optimizers ? ✔ ✔ ✔ ✔ High-Level Virtual Machines ✔ ✔ user code LLVM ✔ ✔ ✔ ✔ ✔
9. How about the LLVM System? • use a low-level (but typed) representation • type information: important high-level analysis • code representation is truly language neutral • offline and runtime native code generation • LLVM contributions (from 2004) • novel features for language independence • typed pointer arithmetic, exception mechanisms • novel capabilities • first to support all 5 capabilities for livelong optimization
10. Hey, we already have HLL VMs (JVM/CLI) • different goals -> different representation • HLL VMs — classes, inheritance, mem. mgnt., runtime, ... • LLVM — calls, load/stores, arithmetics, addressing, ... • implications • managed CLI is not truly language neutral • managed C++: no multiple inheritance, no copy ctors. • cannot optimize VM code into the application code • HLL VMs require specific runtime environments • LLVM complements HLL VMs • “You complete me!” • a HLL VM can be implemented in terms of LLVM
11. LLVM ISA Overview #1 • low-level & target-independent semantics • RISC-like three address code • infinite virtual register set in SSA form • SSA — static single assignment • simple, low-level control flow constructs • load/store instructions with typed-pointers loop: %i.1 = phi int [ 0, %bb0 ], [ %i.2, %loop ] %AiAddr = getelementptr float* %A, int %i.1 call void %Sum(float %AiAddr, %pair* %P) %i.2 = add int %i.1, 1 %tmp.4 = setlt int %i.1, %N br bool %tmp.4, label %loop, label %outloop for (i = 0; i < N; ++i) Sum(&A[i], &P);
12. LLVM ISA Overview #2 • high-level information exposed in the representation • explicit dataflow through SSA form • explicit CFG (control-flow graph), even for exceptions • invoke / unwind • explicit language-independent type information • explicit typed pointer arithmetics loop: %i.1 = phi int [ 0, %bb0 ], [ %i.2, %loop ] %AiAddr = getelementptr float* %A, int %i.1 call void %Sum(float %AiAddr, %pair* %P) %i.2 = add int %i.1, 1 %tmp.4 = setlt int %i.1, %N br bool %tmp.4, label %loop, label %outloop for (i = 0; i < N; ++i) Sum(&A[i], &P);
13. LLVM Type System • the entire type system consists of... • primitives — void, bool, float, ushort, opaque, ... • derived — pointer, array, structure, function • no high-level types, type-system is language netural • source language types are lowered (to low-level) • e.g. T& — T* • e.g. class T : S { int x; } — { S, int } • type system allows arbitrary casts • expressing non-type-safe language, like C • type information in LLVM representation will be checked
14. Pointer Arithmetic — getelementptr • given a pointer, return element address • &A->field_1 — getelementptr {int, int}* A, uint 1 • &B[i] — getelementptr [10 x int]* B, long i • key feature for several high-level analyses • field information for field-sensitive alias analysis • array subscript information for dependence analysis
15. LLVM Exception Handling Support (#1) • provides mechanisms to implement exceptions • don’t specify exception semantics (C, C++, Java) • critical for language independence • provides two simple instructions • invoke — call to a function needing an exception handler • unwind — unwind stack frames until reaching an invoke • supports general stack unwinding • setjmp/longjmp implemented as “exceptions” • full C++ exception handling model is implemented • sufficient for: C, C++, Java, C#, OCaml, ...
16. LLVM Exception Handling Support (#2) // simple C++ example { Class Object; // has a dtor func(); // may throw ... } ; allocate stack space %Object = alloca %Class ; construct object call %Class::Class(%Object) ; call function invoke func() to B1, B2 B1: ... ... B2: ; destroy object call %Class::~Class(%Object) ; continue propagation unwind normal edge unwind edge
17. LLVM Compiler Architecture
18. 5 Key Goals/Capabilities — in LLVM • a persistent, rich code representation • LLVM to LLVM optimizations can happen at any time • offline native code generation • generate high-quality machine code, retaining LLVM • profiling & optimization in the field • runtime & offline profile-driven optimizers • language independence • low-level instruction set & type with transparent runtime • uniform whole-program optimization • optimize across source-language boundries
19. So, Evaluation? • does LLVM enable high-level analysis & optimization? • oh, yes! • how big are programs in LLVM? • almost the same size to x86 binary programs • how reliable is the type information? • is it useful for anything? • yes, it enables optimization (even for C codes) • structure reorganization • how fast is the optimizer? • is it suitable for runtime & interprocedural optimization? • yes, much faster than GCC with -O3
20. Program Size in LLVM (comparison of LLVM, x86, and Sparc)
21. Type Information Reliability Benchmark # Typed # Untyped Typed % 179.art 572 0 100.0% 181.mcf 571 0 100.0% 164.gzip 1654 61 96.4% 186.crafty 9734 383 96.2% 256.bzip2 1011 52 95.1% 175.vpr 4038 371 91.6% 300.twolf 13028 1196 91.6% 183.equake 799 114 87.5% 255.vortex 13397 8915 60.0% 188.ammp 2109 2598 44.8% 176.gcc 25747 33179 43.7% 197.parser 1577 2257 41.1% 253.perlbmk 9678 22302 30.3% 254.gap 6432 15117 29.8% 177.mesa 2811 19668 12.5% Average 68.04% (how many load/store are typed correctly?)
22. LLVM Optimizer (Speed) Performance Benchmark DGE DAE Inline GCC 176.gcc 0.0496 0.1058 0.6455 55.436 253.perlbmk 0.0137 0.0439 0.8861 25.644 177.mesa 0.0051 0.0312 0.0788 20.844 255.vortex 0.1081 0.0539 0.2462 20.621 254.gap 0.0065 0.0384 0.1317 18.250 300.twolf 0.0712 0.0152 0.1742 11.986 186.crafty 0.0016 0.0162 0.0531 9.444 175.vpr 0.0096 0.0082 0.0564 5.804 188.ammp 0.0200 0.0072 0.1085 5.663 197.parser 0.0021 0.0096 0.0516 5.593 164.gzip 0.0018 0.0063 0.0127 1.937 256.bzip2 0.0015 0.0028 0.0122 1.520 181.mcf 0.0010 0.0007 0.0174 1.193 183.equake 0.0000 0.0009 0.0100 0.632 179.art 0.0002 0.0007 0.0085 0.591
23. LLVM Contributions (from 2004) • novel features • as language-independence as machine code, yet support high-level optimization • new abstraction of exceptions • type-safe pointer arithmetic for high-level analysis/ optimization • novel capabilities • first to provide all 5 capabilities • practical
24. Who is using LLVM (to date)? • Adobe System Inc. • optimizer and JIT codegen for the Hydra Language • alchemy C/C++ Compiler for ActionScript Virtual Machine • Apple Inc. • Xcode 3.2+ (latest version is 4.2) • Mac OS X 10.7 & iOS 5+, all built with clang & llvm-gcc • Intel • OpenCL • NVIDIA • OpenCL runtime compiler (clang + llvm-gcc) • REAL Software • optimizer & codegen for RBScript & REAL Studio Compiler
25. Currently
26. LLVM Publications http://llvm.org/pubs/
27. LLVM-GCC 4.2 (#1) • C, C++, Objective-C, Ada, Fortran • standard GCC command line options • supports almost all GCC language features & exts • x86, x86-64, PowerPC, ... • extremely compatible with GCC 4.2 • drop-in replacement
28. LLVM-GCC 4.2 (#2)
30. Runtime Benchmark (#1) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc
31. Runtime Benchmark (#2) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc
32. Runtime Benchmark (#3) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc
33. Runtime Benchmark (#4) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc
34. Runtime Benchmark (#5) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc
35. Clang Static Analysis (in Xcode 4) https://developer.apple.com/library/ios/#recipes/xcode_help-source_editor/Analyze/Analyze.html
36. Thank you