LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation

LLVM: A Compilation Framework forLifelong Program Analysis & Transformation Chris Lattner lattner@cs.uiuc.edu Vikram Adve 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: • Multiple-stages of analysis & transformation: • compile-time, link-time, install-time, run-time, idle-time • Use aggressive interprocedural optimizations • Gather and exploit end-user profile information • Tune the application to the user’s hardware • But what constraints do we have to meet? • Can’t interfere with the build process! • Must support multiple source-languages! • Must integrate with legacy systems and components! Chris Lattner – lattner@cs.uiuc.edu

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

What about previous approaches? Chris Lattner – lattner@cs.uiuc.edu

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

Why not a HLL VM like CLI/JVM? • Differing goals differing representations: • HLL VMs: classes, inheritance, mem. mgmt, runtime… • LLVM: calls, load/stores, arithmetic, addressing, etc… • 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 high-level VMs: • A HLL VM could be implemented in terms of LLVM! Chris Lattner – lattner@cs.uiuc.edu

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

LLVM Instruction Set Overview #1 • Low-level and target-independent semantics • RISC-like three address code • Infinite virtual register set in SSA form • Simple, low-level control flow constructs • Load/store instructions with typed-pointers loop: %i.1 = phiint [ 0, %bb0 ], [ %i.2, %loop ] %AiAddr = getelementptrfloat* %A, int %i.1 callvoid %Sum(float %AiAddr, %pair* %P) %i.2 = addint %i.1, 1 %tmp.4 = setltint %i.1, %N brbool %tmp.4, label %loop, label %outloop for (i = 0; i < N; ++i) Sum(&A[i], &P); Chris Lattner – lattner@cs.uiuc.edu

LLVM Instruction Set Overview #2 • High-level information exposed in the code • Explicit dataflow through SSA form • Explicit control-flow graph (even for exceptions) • Explicit language-independent type-information • Explicit typed pointer arithmetic loop: %i.1 = phiint [ 0, %bb0 ], [ %i.2, %loop ] %AiAddr = getelementptrfloat* %A, int %i.1 callvoid %Sum(float %AiAddr, %pair* %P) %i.2 = addint %i.1, 1 %tmp.4 = setltint %i.1, %N brbool %tmp.4, label %loop, label %outloop for (i = 0; i < N; ++i) Sum(&A[i], &P); Chris Lattner – lattner@cs.uiuc.edu

LLVM Type System Details: • 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 neutral! • Source language types are lowered: • e.g. T&  T* • e.g. class T : S { int X; } { S, int } • Type system allows arbitrary casts: • Allows expressing non-type-safe languages, like C Chris Lattner – lattner@cs.uiuc.edu

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

LLVM Exception Handling Support • Provide mechanisms to implement exceptions • Do not specify exception semantics (C vs C++ vs Java) • Critical for language independence • LLVM provides two simple instructions: • unwind: Unwind stack frames until reaching an invoke • invoke: Call to a function needing an exception handler • Supports general stack unwinding: • setjmp/longjmp implemented as “exceptions” • 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++ { Class Object; // Has a dtor func(); // Might throw ... } LLVM ; Allocate stack space %Object = alloca %Class ; Construct object call %Class::Class(%Object) ; Call function invoke func() to B1, B2 Exception edges are visible to language and target independent optimizers! Unwind Edge Normal Edge B2: ; Destroy object call %Class::~Class(%Object) ; Continue propagation unwind B1: ... Chris Lattner – lattner@cs.uiuc.edu

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

LLVM provides all five capabilities: • 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 and offline profile-driven optimizers • Language independence: • Low-level inst set & types with transparent runtime • Uniform whole-program optimization: • Optimize across source-language boundaries Chris Lattner – lattner@cs.uiuc.edu

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

How reliable is the type info? • Use static analysis to prove type information: • How many loads/stores are typed correctly? • Type info enables optzn: • e.g. structure reorganization • Even for C codes: • Most programs have extensive type information available! • Extensive use of custom allocators is the biggest hurdle 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: • Due to LLVM’s low-level and efficient IR! Optzns trigger many times: • vortex/DGE: 331 funcs, 557 globals • gcc/DAE: 103 args, 96 ret vals • gcc/Inline: 1368 call sites • … DGE = Dead Global (var/func) Elimination DAE = Dead Argument/Retval Elimination Optimization Time (s) Chris Lattner – lattner@cs.uiuc.edu

LLVM Contributions: • Novel features: • As language independent as machine code, yet supports high-level optimizations • New abstraction for exceptions • Type-safe pointer arithmetic for high-level analysis/opzn • Novel capabilities: • First to provide all five capabilities • 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

LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation