Advanced Compiler Techniques

Advanced Compiler Techniques

LIU Xianhua

School of EECS, Peking University

Future Research Directionsof Compilers

“Advanced Compiler Techniques”

Outline

• Introduction & History• Special Purpose Compilers

– Free-standing compilers– Under the hood– Inside applications– In the toolchain– Inside libraries

• New Languages• Just-in-time & Run-time support

2

3

1950s: Just a Compiler, Please The compiler references a runtime, but the

runtime is supplied by the OS at a fixed location in memory FORTRAN runtime: input/output formatting COBOL runtime: also search and sort

OS loader loads the compiler output into memory, transfers control

Address space is small (< 8K word), CPU is slow (< 1,000 instructions/sec.)

Figure of merit: Code Quality Compiler must optimize code for space Compiler must optimize code for speed


4

Inside the Compiler (in concept)

Source Code

Front End

Back End

ExecutableCode

Compiler

Source Code

Back End

ExecutableCode

Compiler

Front End

• Parse source code• Produce abstract syntax tree

(AST)• Produce symbol table

• Generate errors• Syntax errors• Type errors• Unbound references

Source Code

ExecutableCode

Compiler

• Linearize parse tree• Code Analysis

• Basic block analysis• Control- and data-flow graph analysis

• Optimize (machine-independent)

• Redundant and dead code elimination• Code restructuring

• Convert to executable code• Register allocation• Peephole optimization• Branch prediction and tensioning

Back End

Front End


5

1960s: Linkers Programs are growing in size Programs are built with libraries

Libraries provide reusable code fragments

Virtual memory systems are invented Tool chain is in two stages

Compile independent modules Combine the modules using a linker

Figure of merit: Code quality (speed)


6

Tools: Compiler + Linker

Includes external references

Source Code

Front End

Back End

Object Code

Compiler

Source Code

Front End

Back End

Object Code

Source Code

Front End

Back End

Object Code

Linker

Executable Code


7

1970s: Symbolic Debugger OS written in high-level language

Compilers provide sufficient code performance and low-level access

High-level languages provide large runtime libraries in multiple units Static linker pulls only required units into a

given program image Compiler exports symbol table for use by

debugger, not just internal to front-/back-end

Figure of merit: Code quality (speed)


8

Compiler, Linker, Debugger

Source Code

Front End

Back End

Object Code

Compiler

Source Code

Front End

Back End

Object Code

Source Code

Front End

Back End

Object Code

Linker

Running Program

Symbol table(s)

Debugger


9

1980s: Dynamic Loading, Threading To improve OS performance, by reducing physical memory

pressure, read/only parts of libraries are shared between applications Loaded on first reference

OS loader fixes up references to shared libraries – just like the static linkers Not all libraries are loaded into the same virtual address

Concurrency issues addressed in programming languages Locks, monitors, events, polling Order of operations visible across thread boundaries Memory model semantics become an issue Ada™ introduces rendez-vous, other languages have other

constructs Tool chain

Compiler(s) Linker Loader Symbolic debugger

Figure of merit: Code quality (speed, but this is related to space)


10

OS Dynamic Loader

Source Code

Front End

Back End

Object Code

Compiler

Source Code

Front End

Back End

Object Code

Source Code

Front End

Back End

Object Code

Static Linker

OS Loader

Running Program

Symbol table(s)

Debugger

Includes fixups for shared code

Image FileImage File Image File


11

1990s: JITs and Managed Runtimes Garbage Collection goes mainstream

Previously: LISP, APL, SmallTalk 1990s: Java, Jscript, C#, VB

Verification requires runtime to analyze code Verification is similar to front-end compiler work Can be done to native code, but much simpler with an

intermediate language Just-in-time (JIT) compilation increases

performance over pure interpretation Typically by a factor of 5 to 15

Tool chain: split the compiler in two! Linearize the AST to create Intermediate Language (IL) Save symbol table as “metadata” Reorder the chain

Figures of merit: Throughput first, code quality second


12

OS Dynamic Loader (repeat)

Source Code

Front End

Back End

Object Code

Compiler

Source Code

Front End

Back End

Object Code

Source Code

Front End

Back End

Object Code

Static Linker

OS Loader

Running Program

Symbol table(s)

Debugger

Includes fixups for shared code

Image FileImage File Image File


13

OS Dynamic Loader (repeat)

Source Code

Front End

Back End

Object Code

Static Linker

OS Loader

Running Program

Debugger

Image File

Compiler


14

Managed Runtime

Running Program

Debugger

Source Code

Front End

Back End

Object Code

Static Linker

OS Loader

Image File

OS Loader

DynamicLinker

Image File

Back End

Runtime

Compiler Compile

r


15

Managed Runtime

Running Program

Debugger

Source Code

Front End

Back End

Object Code

Static Linker

OS Loader

Image File

OS Loader

DynamicLinker

Image File

Back End

Runtime

Compiler Compile

r

Metadata + Intermediate

Language


16

2000s: Reflection-based Computation Reflection: ability of a program to observe and

possibly modify its structure and behavior Compilers “preserve meaning” but runtime reflection

makes more information visible, so optimizations are more limited

Metadata (symbol table) or equivalent needed at runtime, not just compile/link time

Interactive Development Environments (IDEs) Intellisense™ Refactoring Interactive syntax analysis

Query Integration Builds expression trees (ASTs) at compile time Runtime operations to combine and manipulate them

Figures of merit: “Compiler” and “JIT compiler”: throughput “Pre-JIT” compiler: balance of throughput and code

quality“Advanced Compiler Techniques”

17

Runtime Reflection

Running Program

Debugger

Source Code

Front End

OS Loader

DynamicLinker

Image File

Back End

Metadata + Intermediate

Language

Metadata(symbol table)

DevelopmentEnvironment


18

Compilers, Interpreters, VM…Pre-

processor

ParserCode

Generator

Assembler

Translator

Interpreter

Bytecode

Generator

JIT Compile

r

Program Parse Tree/IR

Assembly Code

Machine Code

Program BytecodeBytecod

eInterpret

er“Advanced Compiler Techniques”

19

Source-to-Source TranslatorPre-

processor

ParserCode

Generator

Assembler

Translator

Interpreter

Bytecode

Generator

JIT Compile

r


Assembly Code

Machine Code


eInterpret


20

InterpretersPre-

processor

ParserCode

Generator

Assembler

Translator

Interpreter

Bytecode

Generator

JIT Compile

r


Assembly Code

Machine Code


eInterpret


21

Traditional CompilersPre-

processor

ParserCode

Generator

Assembler

Translator

Interpreter

Bytecode

Generator

JIT Compile

r


Assembly Code

Machine Code


eInterpret


22

Compilers & VMPre-

processor

ParserCode

Generator

Assembler

Translator

Interpreter

Bytecode

Generator

JIT Compile

r


Assembly Code

Machine Code


eInterpret


23

Compilers & VM with JITCPre-

processor

ParserCode

Generator

Assembler

Translator

Interpreter

Bytecode

Generator

JIT Compile

r


Assembly Code

Machine Code


eInterpret


24

Compilers, Interpreters, VM…Pre-

processor

Parser/Disassembler

CodeGenerat

orAssembl

er

Translator

Interpreter

Bytecode

Generator

JIT Compile

r

Machine Code

Parse Tree/IR

Assembly Code

Machine Code


eInterpret


25

DecompilationPre-

processor

Parser/Disassembler

CodeGenerat

orAssembl

er

Translator

Interpreter

Bytecode

Generator

JIT Compile

r

Machine Code

Parse Tree/IR

Assembly Code

Machine Code


eInterpret


26

Simulator/EmulatorPre-

processor

Parser/Disassembler

CodeGenerat

orAssembl

er

Translator

Interpreter

Bytecode

Generator

JIT Compile

r

Machine Code

Parse Tree/IR

Assembly Code

Machine Code


eInterpret


27

Binary Rewriting/TranslationPre-

processor

Parser/Disassembler

CodeGenerat

orAssembl

er

Translator

Interpreter

Bytecode

Generator

JIT Compile

r

Machine Code

Parse Tree/IR

Assembly Code

Machine Code


eInterpret


Isn’t it a solved problem?

• Machines are constantly changing – Changes in architecture changes in

compilers – new features pose new problems – changing costs lead to different

concerns – old solutions need re-engineering

• Innovations in compilers should prompt changes in architecture – New languages and features

28“Advanced Compiler Techniques”

What are important in a compiler?

1. Correct code 2. Output runs fast 3. Compiler runs fast 4. Compile time proportional to program size 5. Support for separate compilation 6. Good diagnostics for syntax errors 7. Works well with the debugger 8. Good diagnostics for flow anomalies 9. Cross language calls 10.Consistent, predictable optimization 29“Advanced Compiler Techniques”

30

Outline Compilers, compilers,

everywhere Free-standing compilers Under the hood Inside applications In the tool chain Inside libraries

New Languages Correctness & Security Just-in-time & Run-time support


31

Special-Purpose Compilers Compile-to-hardware Aspect-Oriented Programming (AOP)

weaver Parser finds new syntax to mark insertion

points Back-end inserts code snippets for different

aspects More generally: “assembly rewriting”

Work-flow and object design languages Input may be textual or graphic layouts Output may be code or graphic designs


32

Mark-up Compilers XML schema (or DTD: Document Type

Des.) Output: parser Output: deserializer

Web-services Description (WSDL) Output: proxy that parses input and

dispatches Output: code to convert data structure to XML

(“serializer”) XAML (Windows Presentation Framework)

Output: parser Output: executable code

XSL“Advanced Compiler Techniques”

33





34

Modern Hardware: CPU Compile “machine code” to “micro code”

CPU Architecture is the abstraction boundary RISC vs CISC is an old debate x86 and x64 are CISC on the outside, RISC on

the inside Part of the instruction cache

Engineering note: an icache miss now often means a pause to compile in addition to a memory fetch!

Allows innovation in actual hardware while still running existing code Chips optimized for specific usage scenarios Chips take advantage of materials science

advances Chips take advantage of new internal

architectures (multi-core)“Advanced Compiler Techniques”

35

Modern Hardware: Graphics Graphics memory isn’t just for data Very sophisticated compilation steps Parallel execution with CPU Adapts to changing hardware

organization Raster scan vs vector Resolution, speed, synchronization

Adapts to predominant usage pattern Animation 3D Shading


36





37

Databases SQL is a full programming language

Compiled to intermediate form on client Intermediate form is passed to server for

execution Server optimizes the intermediate form to

produce an “execution plan” Query optimization

Additional inputs include Size of tables Frequency of query types Indexing information

Outputs include Executable code Temporary indexes Background indexing requests Updated frequency information


38

Hardware Simulators/Emulators Object code translation at runtime

HP3000 to PA-RISC in 1983 Vax to Alpha in 1990s 32-bit programs on 64-bit hardware

Alternate hardware emulation Device emulators for everything from smart

cards to cell phones to iPod to pocket PCs JIT compilation trades start-up time for

high performance execution Often, but not always, a good trade-off


39

Code Analysis Tools Analyzing API surface

Simple to do with front end ASTs “Remodularizing” implementation

Requires static and dynamic dependency analysis – normal compiler back end work

Requires rebuilding the program, easily done using front end ASTs

Race detection Instrument code at compile time Gather data as it runs under high stress


40

“Tree Shakers” Start with AST tree and appropriate

dependency graph Pull AST nodes found starting at a given

graph node, recursively Convert resulting set of AST nodes to

appropriate output format Example uses:

Subset library based on initial set of types Statically link subset of library for a given

application


41





42

A Modern Interactive Development Environment (IDE) Code editor

Knows the programming language, provides syntax support and context-sensitive name lookup

Project system Tracks the public shape of components Tracks dependencies between components

Build system Orders clean-up, compile, and link operations

Debugger Allows inspection and modification of values at runtime Allows control operations (e.g., breakpoint, continue,

restart) Dynamic Support

Allows program modification interwoven with execution (“edit and continue”)

Global interaction space (“read-eval-print loop”)


43

Compilers in the IDE (I) In the code editor

Incrementally parses the code as it is being entered. Note: must deal with incorrect syntax and partial programs.

Suggests possible completions based on a symbol table. Note: symbol table must include external references maintained by the project system.

Refactoring operations require both syntactic and semantic analysis. Note: refactoring requires information maintained by the project system.

In the debugger Expression evaluation


44

Compilers In the IDE (II) Dynamic support

Edit-and-continue Requires a full, incremental compiler For efficiency, it also requires the ability to

compress the output as a “diff” between the original and the new code

Interactive workspace Like LISP, APL, SmallTalk, Python, etc. Requires

a compiler or an interpreter -- really, a compiler front end to

generate an AST combined with a tree walker to execute the tree.

The compiler must be capable of generating code that uses code and objects resident in the evaluation environment, which generally means a reliance on reflection.


45

Compilers in the Linker The linker sees “the whole program”, so it’s

better positioned to do global analysis Solution: write a compiler

Input language is object file format (native code or IL) Output language is OS image file format

Optimizations: Aggressive in-lining across module boundaries Code motion across module boundaries Full type system analysis (treat leaf types as sealed)

Issues: These flow graphs are *big* The linker doesn’t see the whole program (dynamic

linking) Reflection and dynamic linking reduce permitted

optimizations Or require the ability to back out or recompute

optimizations at runtime


46

Profile-Guided Optimization Idea: Instrument the program, run it with

typical loads, then re-optimize using this profiling data. (Similar to “Hotspot”)

Optimizations: Optimize only “hot” code fragments

So you can spend more time on them Method and basic block reordering to increase

code density Code reordering to optimize branch prediction

and minimize “long” references Cache locality optimizations for data and code


47





48

For the Developer “Regular expression” parsing

Grammar is usually more powerful than regular expressions

Serialization and Deserialization Reflects on data type to be marshalled Generates specialized code to convert

to stream format (serialization) or parse into in-memory format (deserialization)


49

For the Compiler Writer Parser-generators

lex yacc

AST tool kits Microsoft is investing in this area Provides integration into may aspects of the

IDE Executable file format tool kits

Queensland University of Technology PERWAPI Optimization tool kits

Microsoft’s Phoenix project


50

Libraries and Component Technology

Traditional View

ExpandedView

Code(source or binary)

Interface:Provides/Requires

Data Description:Types, Sizes

Partial Code(source or tunable binary)

CodeGenerator

Interface:Abstract Provides/

Requires

Data Description:Types, Sizes

Interface:Device

Dependencies

Data Description:Map Features to

Optimization

Performance:Device,

Data Features

Support for automatic selection, tuning, scheduling, etc.“Advanced Compiler Techniques”

51





52

Why Languages Evolve: Programming languages capture design patterns

Function calls/return Objects/Method Dispatch/Interfaces/Generics Higher-order Functions in C# Iterators (CLU versus C++ versus C#) Access to structured data (LINQ)

Design patterns change over time Increasing complexity with new abstraction conventions Domain-specific uses (Snobol, MATLAB, php, Ruby) New programmer burdens But the new interoperates with the old…

Language constructs support application lifecycle Architecture/development (modules, namespaces, packages) Testing (especially defect analysis/SAL) Performance analysis (especially “the dialog”) Maintenance


53

Manycore Is A New Burden A least three design patterns demand support

Services (a.k.a. Actors, CSP) – asynchronously evolving agents with private state communicating via messages

Forall – (opportunistic) nested data parallelism over partially-ordered slices of data collectionsArray languages/Parallel LINQ/and sharper knives

Transactions – unordered updates to shared state And this ignores locality….

Chapel/X10/Fortress Language bindings facilitate engineering

automation Load balancing Resource management Speculation/Deadlock-recovery


54

But, A New Language? Yes: Isolation + Communication

Many concepts: Domains, processes, messages, channels, contracts, choice, joins, data schema, time, new failure modes

This suggests a domain-specific language for “coordination” interoperable across many existing languages

No, new features: Forall must be tightly integrated

Fewer concepts but interwoven with data abstractions Research: How expensive are safety nets?

Transactions should be tightly integrated to support forall Insufficient to handle just at the coordination level


55

We Need A Spectrum Of SolutionsThe Few

The Many

A handfull of experts building highly-scalable widely-leveraged software

Performance First. Can exploit HPC prior art in parallel programming

Professional Developers somewhere in the middle needing flexibility to be

most productive

The vast majority that have another job to get done and are opportunistic programmers

No surprises: Spend performance to minimize development time/hassle


56

HTML


57

TIOBE


58

Compare the Languages


59

Future Progress Compactability, Open-platform Fusion of the Language Features Further Performance Improvement More Support for Cloud Computing Security & Privacy


60

Engineering a Compiler

• Compiler research will play a crucial role in achieving performance and programmability of single/multi-core hardware.

• What is the state of compilers today?– Roughly 5 year lag between introducing a new

architecture and a robust compiler– Many interesting new architectures fail in the

marketplace due to inadequate software tools• Today’s compilers are complex and monolithic

– GCC has ~12.8M LOC, Open64 has ~13.1M LOC– SUIF has ~500K LOC, LLVM 2M LOC

The best research ideas do not always make it into practice


61





62

Trustable Compiler Verified Compiler Certifying Compiler Validated Compiler Provable Compiler


63

CompCert: Example of Verified Compiler 经过完全证明的 C语言编译器

Xavier Leroy [CACM ’09] Power PC backend

证明？机器可检查证明使用 Coq代码编写并证明抽取出 O’Caml代码运行


64

Certifying & Validated Compiler


65

Provable Compiler


66

Summary


67





Java Virtual Machine

• An abstract computing machine• Own instruction set (Java ISA)• Memory manipulation at runtime

classloader

executionengine

Host OS

The Java API’s class file

user class files

JVM

bytecodes

native method invocation

“Advanced Compiler Techniques” 68

Run-time EnvironmentCompile-time Environment

JavaBytecodes

move locallyor through

network

JavaSource(.java)

JavaCompiler

JavaBytecod

e(.class )

JavaInterpreter

Just in Time

Compiler

Runtime System

Class Loader

BytecodeVerifier

Java Class

Libraries

Operating System

Hardware

JavaVirtualmachine

How it works…!

Base Class Library

Common Language Specification

Common Language Runtime

ADO.NET: Data and XML

VB VC++ VC#Visual Studio.N

ET

ASP.NET: Web Servicesand Web Forms

JScript …

WindowsForms

Framework, Languages, And Tools

“Advanced Compiler Techniques” 70

71

Dalvik & Android


72

Comparison between J2EE and .NET Architectures


JITC vs AOTC• Just-In-Time Compiler (JITC)

– Compile bytecode to machine code at runtime– Compile time are included in execute time– make the maximum use of program execution

information – require some CPU and Memory resources– ex) Jikes RVM, OpenJDK/Hotspot

• Ahead-Of-Time Compiler (AOTC)– Compile bytecode to machine code before

program execution– Able to do heavy optimizations– Can’t know program execution information– ex) LaTTe


Architecture System Overview

• 3 components of Adaptive Optimization System (AOS)– Runtime measurements subsystem– Controller– Recompilation subsystem


Runtime Measurements Subsystem

• Subsystem which produce raw profiling data– Monitor the performance of individual

methods from a hardware performance monitor

• Organizers periodically process and analyze the raw data– the processes data is used by the

Controller 75“Advanced Compiler Techniques”

Controller

• Orchestrates and conducts the other components of AOS system– build an compilation plan using profiling data to

improve their performance• Determines whether it is profitable to recompile

the method– To estimate cost of recompilation, linear model is

used• this model is calibrated offline

– use Cost/Benefit model to make this calculation• analytic model representing the cost and benefits of these

tasks


Recompilation Subsystem

• Recompilation occur– in separate threads from the application

• 3 components of compilation plan– Profiling data– Optimization plan– Instrumentation plan


DBT Techniques


Dynamic ISA Extension


80

The END

Thank You All

Advanced Compiler Techniques

Documents

compiler output

pleasethe compiler

code qualitycompiler

code quality speed

sufficient code performance

large runtime libraries

memoryfortran runtime

shared libraries