Global Optimizations

Size: px

Start display at page:

Download "Global Optimizations"

Hollie Carpenter
6 years ago
Views:

1 Global Optimizations Avi Hayoun, Hodai Goldman and Lior Zur-Lotan January 31, 2016 Contents 1 Global Optimizations Global optimizations and analyses are performed in the context of a whole, single function - given an entire control ow graph of a function. 1.1 Basic Blocks and Control-Flow graphs A basic block is a sequence of IR instructions that has no goto instructions in it, except, maybe, as its last instruction. It has a single entry point (the rst instruction) and a single exit point (the last instruction). 1 Local Optimizations and analyses are performed in the context of single Basic Blocks. A Control Flow graph is a directed graph, where nodes correspond to Basic Blocks. There's an edge between one block and another if execution control can move between the two (if there is a goto from the end of the rst to the beginning of the other). We also add 2 nodes: start (or Entry) and end (or Exit) Control-Flow Graph Example Consider the following IR: 1 x := y + 1; 2 3 t0 := call ReadInput; 4 ifz t0 goto LElse; 5 z := x + 1; 6 goto LFinish; 7 LElse: 8 z := y + 1; 9 LFinish; 10 w := y; 1 For the purpose of structuring the code of a given function into basic blocks, function calls are considered atomic instructions and not control-ow operators. 1

2 11 LLoop: 12 a := w + 1; 13 t0 := call ReadInput; 14 b := a >= t0 15 x := t0; 16 ifnz x goto LEnd: 17 ifz b goto LLoop: 18 LEnd: The CFG for the above code is: 2 Global CSE and CP Common Subexpression Elimination (CSE) and Copy Propagation (CP) are optimizations achieved by substituting expressions. 2.1 Common Subexpression Elimination This optimization searches for common arithmetic expressions between statements and, if possible, substitutes the second arithmetic operation with the result of the rst. For instance: Given the code 1 _t0 := x + 1; 2 y := _t0 * 2; 3 z := x + 1; 2

3 We can reuse _t0 and eliminate the second computation of x + 1, and we get: 1 _t0 := x + 1; 2 y := _t0 * 2; 3 z := _t0 On top of removing redundant computations CSE is used as a pre-step for other optimizations (e.g. Dead Code Elimination) 2.2 Copy Propagation This optimization means that we look for references to variables that were assigned to another variable (i.e. x := y). We replace the reference to one with the reference to the other. For instance, consider the following code: 1 x := _tmp0 + 1; 2 y := x; 3 w := y + 1; 4 z := x + 1; We can replace the x in z := x + 1 with y and get: 1 x := _tmp0 + 1; 2 y := x; 3 w := y + 1; 4 z := y + 1; It may seem meaningless, but reusing a variable that already exists in the CPU cache is faster than fetching a new one from memory. Also, CP can be a pre-step for other optimizations (e.g. CSE or Dead Code Elimination) 2.3 Available Expressions analysis To perform global CSE or CP we must take the entire CFG and apply the Available Expressions analysis on it. Given a CFG we need to know which expression is stored in which variable at each point of the code. Because we are handling code that includes branching, we need to take code branching into account including, how to unite sets of available expressions from two branches. For this we dene 2 notions for each statement: ˆ IN[s] = set of (var, expression) pairs that are available right before executing s ˆ OUT [s] = set of (var, expression) pairs that are available right after executing s To calculate these sets, let s be a statement of the form "a := expr": 3

4 ˆ OUT [s] = (IN[s] {(a, expr)}) \ {s = (v, e) IN[s] USE(s ) DEF (s) (s s v DEF (s))} ˆ IN[s] = {OUT [p] p CF G.P arents(s)} Reminder: DEF (s) - the variables possibly modied by statement s. USE(s) - the variables read by statement s. An algorithm for computing the IN and OUT sets for a CFG: 1 for var in CFG.vars: 2 for expression in CFG.expressions: 3 for block in CFG: 4 add (var, expression) to OUT[block] 5 OUT[Entry] = {} 6 while Not at fixed point: 7 block = choose SimpleBlock from CFG 8 for s=(var, expr) in block.statements: # Iterate block statements in order 9 IN[s] = Intersect(CFG.OUTs.Parents(s)) 10 OUT[s] = Union((var, expr), (IN[s])) \ {(v, e) pairs where v = var or var in e} If all every Basic Block is iterated (at any order) enough times, the algorithm will reach a xed point where the IN and OUT sets no longer change for any block and that's when the algorithm completes. 3 Example Lets take the IR from CFG example and run the Available Expressions analysis on it. We'll then use the analysis result to apply CP and CSE on the code. 4

5 Here's the CFG for the code, as a reminder: 5

6 3.1 Analysis Initial state Before the rst iteration (of the "while" loop) the sets look like this (we're using "{... }" to denote the set of all (var, expr) pairs): 6

7 st iteration After the rst iteration, the rst block's IN set is reduced (emptied) and the OUT set represents the expressions available to any following statement. 7

8 nd iteration We chose to iterate the left branch rst, but the order is meaningless as long as no block is starved. 8

9 rd iteration Now the right branch. 9

10 th iteration Done with the "if" blocks. 10

11 th iteration Analyzing the loop block, remember that the parents of this block are the one containing "w := y;" as well as the loop block itself. 11

12 th iteration After a single iteration in the loop block, we choose to move on the the block right below it. 12

13 th iteration Going back to that loop. 13

14 3.1.9 Last iteration For consistancy with other analyses we also analyse the Exit block 14

15 3.2 Optimization Now that we've completed the analysis, we can use the results to apply optimizations to the code. We'll start with CP (as a pre-step for CSE or Dead Code Eliminiation). From the results we can see that at line 12 (a := w + 1;) we can replace w with y. Now if we re-run Available Expressions analysis again, we'll get the following result: 15

16 Running CSE on this result we see we can apply the optimization on line 8 (substituting z := y + 1; with z := x), resulting in: 16

17 In this instance CP didn't improve our CSE output, but if we run Liveness Analysis on the above CFG we'll see that the assignment at line 10 (w := y;) is now dead code, and can be removed since we don't read this assigned value of w anywhere (we substituted its read operation at line 12 with a read of y). After removing it we get this nal CFG: 17

Global Optimizations

Global Optimizations Avi Hayoun, Ben Eyal and Lior Zur-Lotan January 9, 2017 Contents 1 Global Optimizations 1 1.1 Basic Blocks and Control-Flow graphs.......................... 1 1.1.1 Control-Flow Graph