Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

#include int main (int argc, char* argv[]) { print("Hello World!\n"); return 0; }

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

LLVM

Slide 5

Slide 5 text

Low-Level Virtual Machine

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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 ✔ ✔ ✔ ✔ ✔

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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);

Slide 12

Slide 12 text

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);

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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, ...

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

LLVM Compiler Architecture

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Program Size in LLVM (comparison of LLVM, x86, and Sparc)

Slide 21

Slide 21 text

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?)

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Currently

Slide 26

Slide 26 text

LLVM Publications http://llvm.org/pubs/

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

LLVM-GCC 4.2 (#2)

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

Runtime Benchmark (#1) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc

Slide 31

Slide 31 text

Runtime Benchmark (#2) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc

Slide 32

Slide 32 text

Runtime Benchmark (#3) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc

Slide 33

Slide 33 text

Runtime Benchmark (#4) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc

Slide 34

Slide 34 text

Runtime Benchmark (#5) http://www.phoronix.com/scan.php?page=news_item&px=MTA5Nzc

Slide 35

Slide 35 text

Clang Static Analysis (in Xcode 4) https://developer.apple.com/library/ios/#recipes/xcode_help-source_editor/Analyze/Analyze.html

Slide 36

Slide 36 text

Thank you