CS153: Compilers Lecture 16: Local Optimization II

Similar documents
CS153: Compilers Lecture 15: Local Optimization

CS153: Compilers Lecture 17: Control Flow Graph and Data Flow Analysis

Control-Flow Graphs & Dataflow Analysis. CS4410: Spring 2013

CS153: Compilers Lecture 14: Type Checking

CS Lecture 7: The dynamic environment. Prof. Clarkson Spring Today s music: Down to Earth by Peter Gabriel from the WALL-E soundtrack

CSE 341 Section 5. Winter 2018

CS422 - Programming Language Design

Fall Lecture 3 September 4. Stephen Brookes

CVO103: Programming Languages. Lecture 5 Design and Implementation of PLs (1) Expressions

CS153: Compilers Lecture 23: Static Single Assignment Form

Recap: Functions as first-class values

To figure this out we need a more precise understanding of how ML works

A Functional Evaluation Model

CS153: Compilers Lecture 8: Compiling Calls

Programming Languages

To figure this out we need a more precise understanding of how ML works

15 212: Principles of Programming. Some Notes on Continuations

SML A F unctional Functional Language Language Lecture 19

CS153: Compilers Lecture 7: Simple Code Generation

Lecture #23: Conversion and Type Inference

Conversion vs. Subtyping. Lecture #23: Conversion and Type Inference. Integer Conversions. Conversions: Implicit vs. Explicit. Object x = "Hello";

The Substitution Model

Programming Languages and Techniques (CIS120)

Lecture 11: Subprograms & their implementation. Subprograms. Parameters

CSE341: Programming Languages Lecture 9 Function-Closure Idioms. Dan Grossman Winter 2013

News. CSE 130: Programming Languages. Environments & Closures. Functions are first-class values. Recap: Functions as first-class values

Programming Languages Assignment #7

Verification of an ML compiler. Lecture 3: Closures, closure conversion and call optimisations

CS 242. Fundamentals. Reading: See last slide

CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures. Dan Grossman Autumn 2018

The Substitution Model. Nate Foster Spring 2018

Exercises on ML. Programming Languages. Chanseok Oh

Closures & Environments. CS4410: Spring 2013

CS 11 Haskell track: lecture 1

MIT Introduction to Program Analysis and Optimization. Martin Rinard Laboratory for Computer Science Massachusetts Institute of Technology

Type Declarations. Γ <num> : num [... <id> τ... ] <id> : τ Γ true : bool Γ false : bool Γ e 1 : num Γ e 2 : num Γ. {+ e 1 e 2 } : num

9/23/2014. Why study? Lambda calculus. Church Rosser theorem Completeness of Lambda Calculus: Turing Complete

Lecture #13: Type Inference and Unification. Typing In the Language ML. Type Inference. Doing Type Inference

Programming Languages and Compilers (CS 421)

Processadors de Llenguatge II. Functional Paradigm. Pratt A.7 Robert Harper s SML tutorial (Sec II)

Programs as Data 6 Imperative languages, environment and store, micro-c

Programming Languages and Techniques (CIS120)

A New Verified Compiler Backend for CakeML. Yong Kiam Tan* Magnus O. Myreen Ramana Kumar Anthony Fox Scott Owens Michael Norrish

Formal Semantics. Prof. Clarkson Fall Today s music: Down to Earth by Peter Gabriel from the WALL-E soundtrack

CSE443 Compilers. Dr. Carl Alphonce 343 Davis Hall

Some Advanced ML Features

Programs as data first-order functional language type checking

CS:3820 Programming Language Concepts

Lecture 3: Recursion; Structural Induction

Recap from last time. Programming Languages. CSE 130 : Fall Lecture 3: Data Types. Put it together: a filter function

More Lambda Calculus and Intro to Type Systems

CS558 Programming Languages

CS558 Programming Languages

Type Soundness. Type soundness is a theorem of the form If e : τ, then running e never produces an error

Lecture 13 CIS 341: COMPILERS

Programming Languages

Begin at the beginning

CSE341, Spring 2013, Final Examination June 13, 2013

Lecture 15 CIS 341: COMPILERS

News. Programming Languages. Recap. Recap: Environments. Functions. of functions: Closures. CSE 130 : Fall Lecture 5: Functions and Datatypes

COMP 105 Homework: Type Systems

Lecture 2: Big-Step Semantics

Programming Languages

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

Programming Languages

Programming Language Features. CMSC 330: Organization of Programming Languages. Turing Completeness. Turing Machine.

CMSC 330: Organization of Programming Languages

CSE 130 [Winter 2014] Programming Languages

CSE 341: Programming Languages

Lambda Calculus. Variables and Functions. cs3723 1

CSE 341: Programming Languages

Type Checking and Type Inference

Typical workflow. CSE341: Programming Languages. Lecture 17 Implementing Languages Including Closures. Reality more complicated

Variables and Bindings

Operational Semantics. One-Slide Summary. Lecture Outline

Static Semantics. Lecture 15. (Notes by P. N. Hilfinger and R. Bodik) 2/29/08 Prof. Hilfinger, CS164 Lecture 15 1

CSE341: Programming Languages Lecture 9 Function-Closure Idioms. Dan Grossman Fall 2011

Type checking. Jianguo Lu. November 27, slides adapted from Sean Treichler and Alex Aiken s. Jianguo Lu November 27, / 39

Types, Expressions, and States

CS4410 : Spring 2013

CSE413: Programming Languages and Implementation Racket structs Implementing languages with interpreters Implementing closures

(Refer Slide Time: 4:00)

Side note: Tail Recursion. Begin at the beginning. Side note: Tail Recursion. Base Types. Base Type: int. Base Type: int

Mini-ML. CS 502 Lecture 2 8/28/08

Tail Recursion: Factorial. Begin at the beginning. How does it execute? Tail recursion. Tail recursive factorial. Tail recursive factorial

Types and Type Inference

CSE 130, Fall 2006: Final Examination

Overview. Elements of Programming Languages. Another example. Consider the humble identity function

Overloading, Type Classes, and Algebraic Datatypes

Midterm II CS164, Spring 2006

Programming Languages and Techniques (CIS120)

Lambda calculus. Wouter Swierstra and Alejandro Serrano. Advanced functional programming - Lecture 6

Parsing. Zhenjiang Hu. May 31, June 7, June 14, All Right Reserved. National Institute of Informatics

Local Optimization: Value Numbering The Desert Island Optimization. Comp 412 COMP 412 FALL Chapter 8 in EaC2e. target code

Flang typechecker Due: February 27, 2015

CMSC 330: Organization of Programming Languages

Programming Languages

# true;; - : bool = true. # false;; - : bool = false 9/10/ // = {s (5, "hi", 3.2), c 4, a 1, b 5} 9/10/2017 4

CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Dan Grossman Spring 2011

Principles of Programming Languages

Transcription:

CS153: Compilers Lecture 16: Local Optimization II Stephen Chong https://www.seas.harvard.edu/courses/cs153

Announcements Project 4 out Due today! Project 5 out Due Tuesday Nov 13 (19 days) Project 6 out Due Tuesday Nov 20 (26 days) 2

Today Monadic form Implementation of some local optimizations 3

Monadic Form We will put programs into monadic form A syntactic form that lets us easily distinguish sideeffecting expressions from pure expressions Enable simpler implementations of optimizations Take CS152 to find out why it s called monadic form! Recall: assume that variable names are distinct 4

Monadic Form datatype operand = (* small, pure expressions, okay to duplicate *) Int of int Bool of bool Var of var and value = (* larger, pure expressions, okay to eliminate *) Op of operand Fn of var * exp Pair of operand * operand Fst of operand Snd of operand Primop of primop * (operand list) and exp = (* control & effects: deep thoughts needed here *) Return of operand LetValue of var * value * exp LetCall of var * operand * operand * exp LetIf of var * operand * exp * exp * exp 5

Converting to Monadic Form Similar to lowering to MIPS: operands are either variables or constants. Means we don't have to worry about duplicating operands since they are pure and aren't big. We give a (unique) name to more complicated terms by binding it with a let that will allow us to easily find common sub-expressions. the uniqueness of names ensures we don't run into capture problems when substituting. We keep track of those expressions that are guaranteed to be pure. makes doing inlining or dead-code elimination easy. We flatten out let-expressions. more scope for factoring out common sub-expressions. 6

Example (x+42+y) * (x+42+z) let t2 = x+42 t3 = t2+y t1 = t3 t5 = x+42 t6 = t5+z t4 = t6 t7 = t1*t4 in t7 let t1 = (let t2 = x+42 t3 = t2+y in t3) t4 = (let t5 = x+42 t6 = t5+z in t6) t7 = t1*t4 in t7 let t2 = x+42 t3 = t2+y t6 = t2+z t7 = t3*t6 in t7 7

Some General ML Equations Optimizations in essence rewrite expressions according to equivalences E.g., 1. let x = v in e == e[x v] 2. (fun x -> e) v == let x = v in e 3. let x =(let y = e1 in e2) in e3 == let y = e1 in let x = e2 in e3 4. e1 e2 == let x=e1 in let y=e2 in x y 5. (e1,,en) == let x1=e1 xn=en in (x1,,xn) 8

What About Metrics? We should rewrite when we improve the program E.g., 1. 3 + 4 7 2. (fun x -> e) v let x = v in e 3. let x = v in e e (when x doesn't occur in e) 4. let x = v in e??? e[x v] 9

Let Reduce or Let Expand? Reducing let x = v in e to e[x v] is profitable when e[x v] is no bigger e.g., when x does not occur in e (dead code elimination) e.g., when x occurs at most once in e e.g., when v is small (constant or variable) (constant & copy propagation) e.g., when further optimizations reduce the size of the resulting expression. 10

Let Reduce or Let Expand? Expanding e[x v] to let x = v in e can be good for shrinking code (common sub-expression elimination) E.g., (x*42+y) + (x*42+z) becomes let w = x*42 in (w+y) + (w+z) 11

Reduction Algorithms Constant folding reduce if's and arithmetic when args are constants Operand propagation replace each LetValue(x,Op(w),e) with e[x w] why can't we do LetValue(x,v,e) with e[x v]? Common Sub-Value elimination replace each LetValue(x,v, LetValue(y,v,e), ) with LetValue(x,v, e[y x] ) Dead Value elimination When e doesn't contain x, replace LetValue(x,v,e) with e 12

Constant Folding let rec cfold_exp (e:exp) : exp = match e with Return w -> Return w LetValue(x,v,e) -> LetValue(x, cfold_val v, cfold_exp e) LetCall(x,f,ws,e) -> LetCall(x,f,ws,cfold_exp e) LetIf(x,Bool true,e1,e2,e)-> cfold_exp (flatten x e1 e) LetIf(x,Bool false,e1,e2,e)-> cfold_exp (flatten x e2 e) LetIf(x,w,e1,e2,e)-> LetIf(x,w,cfold e1,cfold e2,cfold e) 13

Flattening Turn let x = e1 in e2 into an exp and flatten (x:var) (e1:exp) (e2:exp):exp = match e1 with Return w -> LetVal(x,Op w,e2) LetVal(y,v,e ) -> LetVal(y,v,flatten x e e2) LetCall(y,f,ws,e ) -> LetCall(y,f,ws,flatten x e e2) LetIf(y,w,et,ef,ec) -> LetIf(y,w,et,ef,flatten x ec e2) 14

Constant Folding ctd. and cfold_val (v:value):value = match v with Fn(x,e) -> Fn(x,cfold_exp e) Primop(Plus,[Int i,int j]) -> Op(Int(i+j)) Primop(Plus,[Int 0,v]) -> Op(v) Primop(Plus,[v,Int 0]) -> Op(v) Primop(Minus,[Int i,int j]) -> Op(Int(i-j)) Primop(Minus,[v,Int 0]) -> Op(v) Primop(Lt,[Int i,int j]) -> Op(Bool(i<j)) Primop(Lt,[v1,v2]) -> if v1 = v2 then Op(Bool false) else v... v -> v 15

Operand Propagation let rec cprop_exp(env:var->oper option)(e:exp):exp = match e with Return w -> Return (cprop_oper env w) LetValue(x,Op w,e) -> cprop_exp (extend env x (cprop_oper env w)) e LetValue(x,v,e) -> LetValue(x,cprop_val env v,cprop_exp env e) LetCall(x,f,w,e) -> LetCall(x,cprop_oper env f, cprop_oper env w, cprop_exp env e) LetIf(x,w,e1,e2,e) -> LetIf(x,cprop_oper env w, cprop_exp env e1, cprop_exp env e2, cprop_exp env e) 16

Operand Propagation ctd and cprop_oper env w = match w with Var x -> (match env x with None -> w Some w2 -> w2) _ -> w and cprop_val env v = match v with Fn(x,e) -> Fn(x,cprop_exp env e) Pair(w1,w2) -> Pair(cprop_oper env w1, cprop_oper env w2) Fst w -> Fst(cprop_oper env w) Snd w -> Snd(cprop_oper env w) Primop(p,ws) -> Primop(p,map (cprop_oper env) ws) Op(_) -> raise Impossible 17

Common Value Elimination let rec cse_exp(env:value->var option)(e:exp):exp = match e with Return w -> Return w LetValue(x,v,e) -> (match env v with None -> LetValue(x,cse_val env v, cse_exp (extend env v x) e) Some y -> LetValue(x,Op(Var y),cse_exp env e)) LetCall(x,f,w,e) -> LetCall(x,f,w,cse_exp env e) LetIf(x,w,e1,e2,e) -> LetIf(x,w,cse_exp env e1,cse_exp env e2, cse_exp env e) and cse_val env v = match v with Fn(x,e) -> Fn(x,cse_exp env e) v -> v 18

Dead Value Elimination (naive) let rec dead_exp (e:exp) : exp = match e with Return w -> Return w LetValue(x,v,e) -> if count_occurs x e = 0 then dead_exp e else LetValue(x,v,dead_exp e) LetCall(x,f,w,e) -> LetCall(x,f,w,dead_exp env e) LetIf(x,w,e1,e2,e) -> LetIf(x,w,dead_exp env e1, dead_exp env e2,dead_exp env e) 19

Comments It s possible to fuse constant folding, operand propagation, common value elimination, and dead value elimination into one giant pass. one env to map variables to operands one env to map values to variables on way back up, return a table of use-counts for each variable. There are plenty of improvements: e.g., sort operands of commutative operations so that we get more common sub-values. e.g., keep an env mapping variables to values and use this to reduce fst/snd operations. LetValue(x,Pair(w1,w2),,LetValue(y,Snd(Op x), ) becomes LetValue(x,Pair(w1,w2),,LetValue(y,Op w2, ) 20

Function Inlining Replace LetValue(f,Fn(x,e1)), LetCall(y,f,w,e2) with LetValue(f,Fn(x,e1)), LetValue(y,LetValue(x,Op w,e1),e2) ) Problems: Monadic form doesn't have nested Let's! (so we must flatten out the nested let.) Bound variables get duplicated (so we rename them as we flatten them out.) 21

When to Inline? Recall heuristics from last week: Expand only function call sites that are called frequently Expand only functions with small bodies Expand functions that are called only once Dead function elimination will remove the now unused function 22

Optimizations So Far... Constant folding Operand propagation copy propagation: substitute a variable for a variable constant propagation: substitute a constant for a variable Dead value elimination Common sub-value elimination Function inlining 23

Optimizing Function Calls We never eliminate LetCall(x,f,w,e) since the call might have effects But if we can determine that f is a function without side effects, then we could treat this like a LetVal declaration. Then we get cse, dce, etc. on function calls! E.g., fact(10000) + fact(10000) becomes let t = fact(10000) in t + t In general, we won't be able to tell if f has effects. Idea: use a modified type-inference to figure out which functions have side effects Idea 2: make the programmer distinguish between functions that have effects and those that do not 24

Optimizing Conditionals if v then e else e becomes e if v then (if v then e1 else e2) else e3 becomes if v then e1 else e3 let x = if v then e1 else e2 in e3 becomes if v then let x=e1 in e3 else let x=e2 in e3 if v then let x=v1 else let y=v1 becomes let z=v1 in if v then let x=z else let y=z (when vars(v1) defined before the if) let x=v1 in (if v then x else (no x) ) becomes if v then (let x=v1 in x ) else (no x) 25