: Compiler Design. 9.5 Live variables 9.6 Available expressions. Thomas R. Gross. Computer Science Department ETH Zurich, Switzerland

Transcription

1 : Compiler Design 9.5 Live variables 9.6 Available expressions Thomas R. Gross Computer Science Department ETH Zurich, Switzerland

2 Outline Warp up reaching definifons Live variables Available expressions 21

3 Food for thought void foo(int x) { } int a, b, c; a = x + 1; if ( ) { b = x; } else { } c = b + 1; return c; // no a, b d1: a = x + 1 if (Tcond) d2: b = x IN = {d1,d2} d3: c = b + 1 return c 22

4 Food for thought void foo(int x) { } int a, b, c; a = x + 1; if ( ) { b = x; } else { } c = b + 1; return c; // no a, b d1: a = x + 1 if (Tcond) d2: b = x IN = {d1,d2} d3: c = x + 1 return c 23

5 Program is broken As far as we can tell, d3 may read an undefined value of b Maybe not cannot decide in general Don t know anything about Tcond Our model is: if there is an edge in the CFG, control may be transferred A consequence 24

6 Food for thought d1: a = x + 1 if (Tcond1) // no a, b d2: b = x d3: a = y + 1 if (Tcond?) d5: c = a + 1 return c IN = {d3,d2} // no a, b d4: c = b

7 Program is broken d4 may read an undefined value of b Or if Tcond? == TCond1 it does not read an undefined value But we do not know there is a path along which b is undefined Could we use reaching definifons to idenffy such trouble spots Back to the use of flow analysis for program checking 26

8 UniniFalized variables Reaching definifons: set of definifons that reach start of a basic block Idea: insert fake definifons into the ENTRY node One for each variable fake means there is no correspondence in the source program IdenZfy by tag, number,.. (here number > 100) Start iterazon with OUT(ENTRY) = set of fake definizons If a fake definifon d that sets desfnafon dest reaches a block B, and there is a use of dest in B prior to any definifon of dest in B, then dest is potenfally uninifalized Compiler can (in general) only issue warning, cannot be sure variable is uninizalized 27

9 UniniFalized variables d100: a = d101: b = d102: c = ENTRY IN: {d1, d101, d102} IN: {d3,d2, d101, d102} IN: {d100, d101, d102} // no a, b IN: {d1,d2, d101, d102} d1: a = x + 1 if (Tcond1) d3: a = y + 1 if (Tcond2) d2: b = x IN: {d1,d101,d102} IN: {d3,d2,d101, d102} // no a, b d4: c = b + 1 IN: {d3,d2,d4,d101, d102} x or y are fields or parameters so we do not need a fake definizon d5: c = a + 1 return c EXIT 28

10 UniniFalized variables d100: a = d101: b = ENTRY // no a or b if (Tcond1) d1: a = x + 1 d2: b = x + 2 IN: {d1,d2, d101, d100} x or y are fields or parameters so we do not need a fake definizon d3: x = a + 1 d4: b = y + 1 d5: y = b + 1

11 UniniFalized variables ENTRY d100: a = // no a or b if (Tcond1) d1: a = x + 1 d2: a = x + 2 IN: {d1,d2} d3: a = a + 1 return a x is a field or parameter so we do not need a fake definizon

12 Program analysis Compiler needs informafon Specific problem Devise flow analysis to compute informafon Let compiler use informafon to deal with specific problem 31

13 9.5 Live variables FoundaFons for several opfmizafons If a variable is not live, it s dead. No need to store value in dead variables Outline Data flow problem Transfer funczon Examples 32

14 Wishlist Given a statement S dest = operand1 operand2 Compiler would like to know at point P if there is a further use of dest I.e., there is a statement S that uses dest and there is a path from P to P before_s One interesfng point is P aaer_s or P aaer_b (with B the basic block of S) But every point could be interesfng Like to know if operandx is used again in another statement 33

15 Data flow problem Similar to reaching definifons but not interested what has happened prior to reaching P but what happens aaer P Consider all paths that start at P and go to EXIT A variable V is live at point P if there is a path from P to EXIT that contains a statement S that uses V, and there is no definifon of V on this path between P and S. Path can start anywhere Ojen we care about paths that start ajer a definizon of V A single path with a use is enough for V to be live at P A variable that is not live is called dead. Recall that we assume all statements have clearly idenffiable operands and desfnafons 34

16 Live variables Live variable analysis determines for all points P the set of variables that are live. We care primarily about live variables at the end of a basic block. Handling a basic block is easy if we know what s live at the end There are many opfmizafons that are based on live variable analysis If a variable is dead at P then it s not necessary to store the variable If a register is needed and one of the registers contains a dead variable, this register can be used right away no need to save the current content 35

17 No need to store value computed by S2 in variable W If expr has no side effect stmt can be removed V is local to basic block B If Y is in a register this register can be released aaer S4 S1: V = S2: W = expr S3: = X V S4: = Y 1 S5: = Z Live = { X, Z} B 36

18 Transfer funcfon d: = var B var is live at the start of basic block B if there is no stmt in B prior to d that defines var 37

19 Transfer funcfon d: = var d : var = var is live at the start of basic block B if there is no stmt in B prior to d that defines var 38

20 Transfer funcfon d : var = d: = var var is not live at the start of basic block B as there is a stmt in B prior to d that defines var DefiniZon d 39

21 Transfer funcfon d: = var Define for basic block B def B = { var var is defined in B prior to any use of var in B } use B = { var var is used in B prior to any definizon of var in B } 40

22 Transfer funcfon d: = var Define for basic block B def B = { var var is defined in B and there is no use of var in B } use B = { var var is used in B and there is no definizon of var in B } DefiniFons and uses of a variable: must be conservafve In def only if we are sure the variable is set In use if there is a chance that the value is used 41

23 Transfer funcfon NoFce that we may be interested in the set of live variables at the start of a basic block Determined by statements in basic block and statements in subsequent basic blocks Eventually we also figure out what s live at the end of a basic block Set of live variables at the end of a basic block Determined by statements in subsequent basic blocks Another term: live == downward exposed 42

24 Transfer funcfon IN(B) = {v 1, v 2,, v n } d: = var For a basic block B we define IN(B) = { var var live at P before_b } OUT(B) = { var var live at P ajer_b } OUT(B) = {v 1, v 2,, v m } Variable v IN(B) v is used in B prior to any definizon, i.e. v use B v OUT(B) and v not set by statements in B, i.e. v def B IN(B) = use B (OUT(B) def B ) 43

25 Transfer funcfon B2 B3... B1 Given IN(B1) What should be OUT(B2) and OUT(B3)? OUT(B2) = IN(B1), OUT(B3) = IN(B1) 44

26 Transfer funcfon... B1 B2 B3 Given IN(B2) and IN(B3) What should be OUT(B1)? A variable var is live at a point P if there is a path from P to EXIT such that var is used along that path prior to any definizon Must consider all paths starzng at P 45

27 Transfer funcfon... B1 B2 B3 Given IN(Bi) OUT(B) = Bi, Bi is successor of B in CFG IN(Bi) 46

28 Finding IN and OUT def B and use B capture what happens inside a basic block. 47

29 Example ENTRY d1: i = m 1 d2: j = n d3: a = d4: i = i + 1 d5: j = j - 1 d6: a = d7: i = From Aho et al Compilers, p 604 EXIT 48

30 Example def = {i, j, a} use = {m, n } ENTRY d1: i = m 1 d2: j = n d3: a = def = {} use = {i, j} d4: i = i + 1 d5: j = j - 1 def = {a} use = d6: a = def = {i} use = d7: i = From Aho et al Compilers, p 604 EXIT 49

31 Finding IN(B) and OUT(B) N basic blocks, 2 N sets IN / OUT System with 2 N unknowns Solve by iterazng unzl a fixed point is found How to start iterafon? Safe assumpzon IN[EXIT] = Nothing is live at the end 50

32 Finding live variables IN[EXIT] = IniZalize IN[B] = for B EXIT while (changes to any IN(B)) { for (each basic block B EXIT) { OUT(B) = Bi, Bi is successor of B in CFG IN(Bi) IN(B) = use B (OUT(B) def B ) } } 51

33 Example def = {i, j, a} use = {m, n } ENTRY d1: i = m 1 d2: j = n d3: a = def = {} use = {i, j} d4: i = i + 1 d5: j = j - 1 def = {a} use = d6: a = def = {i} use = d7: i = From Aho et al Compilers, p 604 EXIT 52

34 Example def = {i, j, a} use = { m, n } ENTRY d1: i = m 1 d2: j = n d3: a = IN(B1) {m,n} OUT(B1) {i,j} def = {} use = {i, j} d4: i = i + 1 d5: j = j - 1 IN(B2) OUT(B2) {i,j} {j} d6: a = def = {a} use = def = {i} use = IN(B3) {j} OUT(B3) {j} d7: i = IN(B4) OUT(B4) {j} {i,j} From Aho et al Compilers, p 604 EXIT IN(EXIT) 53

35 Comments The set use B includes also uses in statements that are not assignment statements Expression in if-then statements Expressions in while loops Actuals in method calls The order of visifng the basic blocks (in main loop) determines how fast the fixed point is found But not the final result There may be other solufons that are also correct 54

36 Summary Reaching definifons and live variables require a similar approach Compute two sets for each basic block B SoluZon = OUT(B) / IN(B) Context = IN(B) / OUT(B) Two sets to capture local effects local_cut = def B (but with different meaning: sets of definizons/sets of variables) local_new = gen B / use B Init SoluZon(ENTRY) / SoluZon(EXIT) i.e. OUT(ENTRY) / IN(EXIT) Init remaining SoluZon sets Iterate over basic blocks B Context(B) = Bi, Bi is predecessor/successor of B in CFG SoluZon(Bi) SoluZon(B) = local_new B (Context(B) local_cut B ) 55

37 Def-use and use-def chains Store informafon about reaching definifons and live variables as lists For each use of a variable include in the list all definizons that reach this use (use-def chain) For each point P (definizon of a variable) include in the list all uses of this variable DU chains or UD chains for short Can be obtained directly from solufon to global data flow problem 56

38 57

39 DU chain def = {i, j, a} use = { m, n } ENTRY d1: i = m 1 d2: j = n d3: a = IN(B1) {m,n} OUT(B1) {i,j} def = {} use = {i, j} d4: i = i + 1 d5: j = j - 1 IN(B2) OUT(B2) {i,j} {j} d6: a = def = {a} use = def = {i} use = IN(B3) {j} OUT(B3) {j} d7: i = IN(B4) OUT(B4) {j} {i,j} From Aho et al Compilers, p 604 EXIT IN(EXIT) 58

40 ENTRY UD/DU chains Show the DU and UD chains r = 3 s = t t = u r = r + 1 v = r * s s = 0 s = s + 1 u = r + s w = u + 2 EXIT 59

41 60

42 Flow of informafon Reaching definifon: j ENTRY d1: i = m 1 d2: j = n d3: a = d4: = i + 1 d5: j = j - 1 d6: a = i + 1 d7: i = EXIT 61

43 62

44 Flow of informafon Live variable: i ENTRY d1: i = m 1 d2: j = n d3: a = d4: = i + 1 d5: j = j - 1 d6: a = i + 1 d7: i = EXIT 63

45 Flow of informafon Live variable: j ENTRY d1: i = m 1 d2: j = n d3: a = d4: = i + 1 d5: j = j - 1 d6: a = i + 1 d7: i = EXIT 64

46 ImplicaFons Should try to propagate informafon in the direcfon of the flow For speed of conversion, not for correctness Reaching definifons: forward problem InformaZon flows in the direczon of the CFG, from ENTRY to EXIT Live variables: backward problem InformaZon flows from EXIT to ENTRY 65

47 ImplementaFon ENTRY d1: i = m 1 d2: j = n d3: a = d4: i = i + 1 d5: j = j - 1 d6: a = d7: i = Flow graph as used when EXIT compufng reaching definifons 66

48 ImplementaFon EXIT d1: i = m 1 d2: j = n d3: a = d4: i = i + 1 d5: j = j - 1 d6: a = d7: i = Flip flow graph when compufng ENTRY live variables 67

49 Program analysis Compiler needs informafon Specific problem Devise flow analysis to compute informafon Can we think of other kinds of informafon that might be useful to the compiler? 68

50 9.6 Available expressions x = a + b if (Tcond1) B1 // no change to a,b // no change to a,b y = a + b Expression a+b evaluated twice: in B1 and B4 B4 Q1: Can we determine that a+b in B1 yields the idenfcal result as a+b in B4? Q2: Does it make sense to reuse the value from B1? Postpone the answer to last queszon Q2 69

51 Available expressions An expression a+b is available at a point P if a+b is evaluated on every path from ENTRY to P and there is no definifon of a or b on this path aaer a+b was evaluated Interested in set of expressions available at the start of a basic block B Set depends on paths that lead to P before_b Assume that a+b has no side effects Reading a memory locazon may have side effects too! Not a problem for JavaLi or Java 70

52 Available expressions e1: x = a + b if (Tcond) B1 B2?? Is a+b computed in e1 available for e2? Available at P Depends on B2 P e2: y = a + b B3 71

53 Available expressions e1: x = a + b if (Tcond) B1 B2 a = Is a+b computed in e1 available for e2? No a may have at P a value that differs from the value at e1. P e2: y = a + b B3 72

54 Available expressions e1: x = a + b if (Tcond) B1 B2 a = e3: z = a + b Is a+b available for e2? Yes either computed by e1 or by e3 P e2: y = a + b B3 73

55 Transfer funcfon e: = a + b B a+b is available at the end of basic block B if there is no stmt in B that follows e and that defines a or b Must be conservazve If a statement in the shaded region may modify a (or b) then a+b is not available at the end of B 74