LLVM A Compilation Framework for Lifelong Program Analysis

LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation Chris Lattner Vikram Adve lattner@cs. uiuc. edu vadve@cs. uiuc. edu http: //llvm. cs. uiuc. edu/ 2004 International Symposium on Code Generation and Optimization (CGO’ 04) March 22, 2004

Life-Long Program Optimization: n Multiple-stages of analysis & transformation: v compile-time, link-time, install-time, run-time, idle-time v Use aggressive interprocedural optimizations v Gather and exploit end-user profile information v Tune the application to the user’s hardware n But what constraints do we have to meet? v Can’t interfere with the build process! v Must support multiple source-languages! v Must integrate with legacy systems and components! Chris Lattner – lattner@cs. uiuc. edu

Five key capabilities are needed: 1. A persistent, rich code representation n Enables analysis & optimization throughout lifetime 2. Offline native code generation n Must be able to generate high-quality code statically 3. Profiling & optimization in the field n Adapt to the end-user’s usage patterns 4. Language independence n No runtime, object model, or exception semantics 5. Uniform whole-program optimization n Allow optimization across languages and runtime Chris Lattner – lattner@cs. uiuc. edu

What about previous approaches? Approach Persistent Rich Code Source-level Compilers Offline End-user Transparent Uniform Codegen Profiling runtime whole-prog. Source-level Link-time IPO through link-time Machine Code Optimizers High-Level Virtual Machines ? LLVM user code only Chris Lattner – lattner@cs. uiuc. edu

Our approach: The LLVM System n Use a low-level, but typed, representation: v Type information allows important high-level analysis v Code representation is truly language neutral v Allow off-line and runtime native code generation n Our specific contributions: v Novel features for language independence: n Typed pointer arithmetic, exception mechanisms v Novel capabilities: n First to support all 5 capabilities for lifelong optzn: Chris Lattner – lattner@cs. uiuc. edu

Why not a HLL VM like CLI/JVM? n Differing goals differing representations: v HLL VMs: classes, inheritance, mem. mgmt, runtime… v LLVM: calls, load/stores, arithmetic, addressing, etc… n Implications: v Managed CLI is not truly language neutral: Managed C++: No multiple inheritance, no copy ctors n Cannot optimize VM code into the application code n v HLL VMs require specific runtime environments n LLVM complements high-level VMs: v A HLL VM could be implemented in terms of LLVM! Chris Lattner – lattner@cs. uiuc. edu

Outline n n n Introduction, problem statement LLVM Virtual Instruction Set LLVM Compiler Architecture Evaluation Summary Chris Lattner – lattner@cs. uiuc. edu

LLVM Instruction Set Overview #1 n Low-level and target-independent semantics v RISC-like three address code v Infinite virtual register set in SSA form v Simple, low-level control flow constructs v Load/store instructions with typed-pointers loop: %i. 1 = phi int [ 0, %bb 0 ], [ %i. 2, %loop ] %Ai. Addr = getelementptr float* %A, int %i. 1 for (i = 0; i < N; call void %Sum(float %Ai. Addr, %pair* %P) ++i) %i. 2 = add int %i. 1, 1 Sum(&A[i], &P); %tmp. 4 = setlt int %i. 1, %N br bool %tmp. 4, label %loop, label %outloop Chris Lattner – lattner@cs. uiuc. edu

LLVM Instruction Set Overview #2 n High-level information exposed in the code v Explicit dataflow through SSA form v Explicit control-flow graph (even for exceptions) v Explicit language-independent type-information n Explicit typed pointer arithmetic loop: %i. 1 = phi int [ 0, %bb 0 ], [ %i. 2, %loop ] %Ai. Addr = getelementptr float* %A, int %i. 1 for (i = 0; i < N; call void %Sum(float %Ai. Addr, %pair* %P) ++i) %i. 2 = add int %i. 1, 1 Sum(&A[i], &P); %tmp. 4 = setlt int %i. 1, %N br bool %tmp. 4, label %loop, label %outloop Chris Lattner – lattner@cs. uiuc. edu

LLVM Type System Details: n The entire type system consists of: v Primitives: void, bool, float, ushort, opaque, … v Derived: pointer, array, structure, function v No high-level types: type-system is language neutral! n Source language types are lowered: v e. g. T& T* v e. g. class T : S { int X; } { S, int } n Type system allows arbitrary casts: v Allows expressing non-type-safe languages, like C Chris Lattner – lattner@cs. uiuc. edu

Pointer Arithmetic: getelementptr n Given a pointer, return element address: v “getelementptr {int, int}* A, uint 1” v “getelementptr [10 x int]* B, long n &A->field 1 i” &B[i] A key feature for several high-level analyses: v Field information for field-sensitive alias analysis v Array subscript info for dependence analysis Chris Lattner – lattner@cs. uiuc. edu

LLVM Exception Handling Support n Provide mechanisms to implement exceptions v Do not specify exception semantics (C vs C++ vs Java) v Critical for language independence n LLVM provides two simple instructions: v unwind: Unwind stack frames until reaching an invoke v invoke: Call to a function needing an exception handler n Supports general stack unwinding: v setjmp/longjmp implemented as “exceptions” v Full C++ exception handling model is implemented Sufficient for: C, C++, Java, C#, OCaml, etc. Chris Lattner – lattner@cs. uiuc. edu

A simple C++ example: C++ LLVM { Class Object; // Has a dtor func(); // Might throw. . . } ; Allocate stack space %Object = alloca %Class ; Construct object call %Class: : Class(%Object) ; Call function invoke func() to B 1, B 2 Exception edges are visible to language and target independent optimizers! Unwind Edge Normal Edge B 2: ; Destroy object B 1: call %Class: : ~Class(%Object). . . ; Continue propagation unwind Chris Lattner – lattner@cs. uiuc. edu

Outline n n n Introduction, problem statement LLVM Virtual Instruction Set LLVM Compiler Architecture Evaluation Summary Chris Lattner – lattner@cs. uiuc. edu

LLVM Compiler Architecture C, C++ Fortran OCAML Compiler 1 LLVM C, C++ JVM MSIL Compiler N LLVM • • • Linker + IP Optimizer Offline Optimizer LLVM Shared Libraries Developer User site Native or LLVM Profile info JIT Profile info Runtime Optimizer Static Code Gen Chris Lattner – lattner@cs. uiuc. edu

LLVM provides all five capabilities: 1. A persistent, rich code representation: n LLVM to LLVM optimizations can happen at any time 2. Offline native code generation: n Generate high-quality machine code, retaining LLVM 3. Profiling & optimization in the field: n Runtime and offline profile-driven optimizers 4. Language independence: n Low-level inst set & types with transparent runtime 5. Uniform whole-program optimization: n Optimize across source-language boundaries Chris Lattner – lattner@cs. uiuc. edu

Outline n n n Introduction, problem statement LLVM Virtual Instruction Set LLVM Compiler Architecture Evaluation Summary Chris Lattner – lattner@cs. uiuc. edu

Evaluation Overview n Does LLVM enable high-level analysis/optzn? See paper v Yes! n How big are programs in LLVM? v Comparable to native machine code binaries n How reliable is the type information? v Is it useful for anything? n How fast is the optimizer? v Is it suitable for run-time & interprocedural optimization? Chris Lattner – lattner@cs. uiuc. edu

How reliable is the type info? n Use static analysis to prove type information: v n Type info enables optzn: v n How many loads/stores are typed correctly? e. g. structure reorganization Even for C codes: Most programs have extensive type information available! v Extensive use of custom allocators is the biggest hurdle v 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. bzip 2 1011 52 95. 1% 175. vpr 4038 371 91. 6% 13028 1196 91. 6% 799 114 87. 5% 255. vortex 13397 8915 60. 0% 188. ammp 2109 2598 44. 8% 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% 300. twolf 183. equake 176. gcc Average 68. 04% Chris Lattner – lattner@cs. uiuc. edu

How fast is the LLVM optimizer? IPO takes trivial time compared to GCC, even though GCC has no intermodule optimization: v Due to LLVM’s low-level and efficient IR! Optzns trigger many times: v vortex/DGE: 331 funcs, 557 globals v gcc/DAE: 103 args, 96 ret vals v gcc/Inline: 1368 call sites v … DGE = Dead Global (var/func) Elimination DAE = Dead Argument/Retval Elimination 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. bzip 2 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 Optimization Time (s) Chris Lattner – lattner@cs. uiuc. edu

LLVM Contributions: n Novel features: v As language independent as machine code, yet supports high-level optimizations v New abstraction for exceptions v Type-safe pointer arithmetic for high-level analysis/opzn n Novel capabilities: v First to provide all five capabilities v Practical LLVM is open source, has real users, and really works: try it out! http: //llvm. cs. uiuc. edu/ Chris Lattner – lattner@cs. uiuc. edu