Compiler Design Spring 2017

Transcription

1 Compiler Design Spring Reaching definitions Dr. Zoltán Majó Compiler Group Java HotSpot Virtual Machine Oracle Corporation

2 Admin issues Brief reminder: Code review takes place 15:15 You ve received room information by 33

3 Last lecture: Definition (of reaching definitions) A definition d reaches a point P if there is a path from d to P such that d is not killed along that path. Remember: There are arbitrarily many paths Not feasible to reason / process all of them Reason about claims at program points instead Example claim: D=={d 1, d 2, d 5 P before_s D is the set of definitions that reaches P before_s How do we define a appropriate transfer function? 34

4 Transfer function d 1 : var = d 1 reaches the end of the basic block if there is no statement following d 1 that might kill d 1 Define for basic block B kill B = { d d is killed in B } gen B ={ d d appears in B and no subsequent statement in B kills d } 35

5 a: {d 1, d 2, d 3, d 5 } b: {d 4 } c: {d 6 } gen = {d 2 } kill = {d 1, d 2, d 3, d 5 } d 1 : a = b + 1 d 2 : a = if (Tcond) gen = {d 3 } kill = {d 1, d 2, d 5 } d 3 : a = d 4 : b = gen = {d 4 } kill = P gen = {d 5, d 6 } kill = {d 1, d 2, d 3 } d 5 : a = d 6 : c = 40

6 Running example i: {d 1, d 4, d 7 } j: {d 2, d 5 } a: {d 3, d 6 } gen = {d 1, d 2, d 3 } kill = {d 4, d 5, d 6, d 7 } gen = {d 4, d 5 } kill = {d 1, d 2, d 7 } ENTRY d 1 : i = m 1 d 2 : j = n d 3 : a = d 4 : i = i + 1 d 5 : j = j - 1 gen = {d 6 } kill = {d 3 } d 6 : a = gen = {d 7 } kill = {d 1, d 4 } d 7 : i = From Aho et al Compilers, p 604 EXIT 43

7 Transfer function d 1 : var = So far: Effect of a basic block in isolation kill B = { d d is killed in B } gen B ={ d d appears in B and no subsequent statement in B kills d } (Local analysis) How do we extend transfer functions to definitions that reach P before_b and P after_b 44

8 Transfer function IN(B) = {d 1, d 2,, d n } d : var = For a basic block B we define IN(B) = { d d reaches P before_b } OUT(B) = { d d reaches P after_b } d OUT(B) OUT(B) = {d 1, d 2,, d m } d is in B and reaches the end of B, i.e. d gen B d IN(B) and d not killed by statements in B, i.e. d kill B OUT(B) = gen B (IN(B) kill B ) 45

9 Transfer function... B1 B2 B3 Given OUT(B1). What should be IN(B2) and IN(B3)? IN(B2) = OUT(B1), IN(B3) = OUT(B1) 46

10 47

11 Transfer function B2 B3... B1 Given OUT(B2) and OUT(B3) What should be IN(B1)? A definition d reaches a point P if there is a path from d to P such that d is not killed along that path. Must consider all paths leading to P 48

12 49

13 Transfer function B2 B3... B1 Given OUT(B i ) IN(B) = B i, Bi is predecessor of B in CFG OUT(B i ) 50

14 We have the ingredients (again) Control flow (basic blocks, CGF), points, paths Same as for constant propagation in previous lecture Transfer function Specific for reaching definitions How does the analysis work? 51

15 Simplifications in examples Do not show points before/after basic block Omit conditional test Evaluation of condition If statement Capture control transfers through edges No explicit jump or branch statements 52

16 i: {d 1, d 4, d 7 } j: {d 2, d 5 } a: {d 3, d 6 } gen = {d 1, d 2, d 3 } kill = {d 4, d 5, d 6, d 7 } ENTRY d 1 : i = m 1 d 2 : j = n d 3 : a = IN(B1) =? OUT(B1) =? gen = {d 4, d 5 } kill = {d 1, d 2, d 7 } d 4 : i = i + 1 d 5 : j = j - 1 IN(B2) =? OUT(B2) =? gen = {d 6 } kill = {d 3 } d 6 : a = IN(B3) =? OUT(B3) =? gen = {d 7 } kill = {d 1, d 4 } d 7 : i = IN(B4) =? OUT(B4) =? From Aho et al Compilers, p 604 EXIT 53

17 Finding IN(B) and OUT(B) gen and kill capture what happens inside a basic block Or the effect of each statement We need IN and OUT for each basic block IN(B) = Bi, Bi is predecessor of B in CFG OUT(Bi) OUT(B) = gen B (IN(B) kill B ) N basic blocks, 2 N sets IN / OUT 54

18 Finding IN(B) and OUT(B) (cont d) System with 2 N unknowns Solve by iterating until a fixed point is found How to start iteration? Safe assumption OUT[ENTRY] = 55

19 Finding reaching definitions OUT[ENTRY] = Initialize OUT[B] = for B ENTRY while (changes to any OUT(B)) { for (each basic block B ENTRY) { IN(B) = B i, Bi is predecessor of B in CFG OUT(B i ) OUT(B) = gen B (IN(B) kill B ) } } 56

20 Finding reaching definitions OUT[ENTRY] = Initialize OUT[B] = for B ENTRY while (changes to any OUT(B)) { for (each basic block B ENTRY) { IN(B) = B i, Bi is predecessor of B in CFG OUT(B i ) OUT(B) = gen B (IN(B) kill B ) } } 57

21 59

22 Initialize OUT[B] = while (changes to any OUT(B)) { for (each basic block B ENTRY) { IN(B) = B i, Bi is predecessor of B in CFG OUT(B i ) OUT(B) = gen B (IN(B) kill B ) } gen = {d 1, d 2, d 3 } kill = {d 4, d 5, d 6, d 7 } ENTRY d 1 : i = m 1 d 2 : j = n d 3 : a = IN(B1) OUT(B1) {d1,d2,d3} gen = {d 4, d 5 } kill = {d 1, d 2, d 7 } d 4 : i = i + 1 d 5 : j = j - 1 IN(B2) OUT(B2) {d1,d2,d3,d5,d6,d7} {d3,d4,d5,d6} gen = {d 6 } kill = {d 3 } d 6 : a = IN(B3) OUT(B3) {d3,d4,d5,d6} {d4,d5,d6} gen = {d 7 } kill = {d 1, d 4 } d 7 : i = IN(B4) OUT(B4) {d3,d4,d5,d6} {d3,d5,d6,d7} EXIT 60

23 Comments Solution not unique Could always use OUT(B) = all definitions Not really useful Iterative algorithm finds least fixed point Order of visiting basic blocks matters For speed of iteration, not for the result Iteration terminates Finite number of basic blocks, finite number of definitions IN and OUT can only grow 61

24 Why? void foo(int x) { } int a, b, c; a = x + 1; b = a; if ( ) { } else { } c = b + 1; return c; // no a, b d 1 : a = x + 1 d 2 : b = a if (Tcond) d 3 : c = b + 1 return c // no a, b IN = {d 1,d 2 } 62

25 Why? void foo(int x) { } int a, b, c; a = x + 1; b = a; if ( ) { } else { } c = b + 1; return c; // no a, b d 1 : a = x + 1 d 2 : b = a if (Tcond) d 3 : c = a + 1 return c // no a, b IN = {d 1,d 2 } 63

26 Comments Change appears to be minor but it is not d 2 can be removed (if there is no other use of b see next topic) Value of variable a can be picked up from register There are other reasons for the compiler to compute reaching definitions 64

27 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 d 1 : a = x + 1 if (Tcond) d 2 : b = x IN = {d 1,d 2 } d3: c = b + 1 return c 65

28 66

29 Food for thought d 1 : a = x + 1 if (Tcond1) // no a, b d 2 : b = x d 3 : a = y + 1 if (Tcond2) d 5 : c = a + 1 return c IN = {d 3,d 2 } // no a, b d 4 : c = b

30 Program is broken As far as we can tell, d 4 may read an undefined value of b Maybe not cannot decide in general Could we use reaching definitions to identify such trouble spots Back to the use of flow analysis for program checking 68

31 Uninitialized variables Reaching definitions: set of definitions that reach start of a basic block Idea: insert fake definitions into the ENTRY node One for each variable fake means there is no correspondence in the source program Identify by tag, number, (here number > 100) Start iteration with OUT(ENTRY) = set of fake definitions If a fake definition d that sets destination dest reaches a block B, and there is a use of dest in B prior to any definition of dest in B, then dest is potentially uninitialized Compiler can (in general) only issue warning, cannot be sure variable is uninitialized 69

32 Uninitialized variables d 100 : a = d 101 : b = d 102 : c = ENTRY IN: {d 1, d 101, d 102 } IN: {d 3,d 2, d 101, d 102 } IN: {d 100, d 101, d 102 } IN: {d 1,d 2, d 101, d 102 } // no a, b d 1 : a = x + 1 if (Tcond1) d3: a = y + 1 if (Tcond2) d2: b = x IN: {d 1,d 101,d 102 } IN: {d 3,d 2,d 101, d 102 } // no a, b d4: c = b + 1 IN: {d 3,d 2,d 4,d 101, d 102 } x or y are global or parameters so we do not need a fake definition d5: c = a + 1 return c EXIT 70

33 71

34 Uninitialized variables d 100 : a = d 101 : b = ENTRY // no a or b if (Tcond1) d 1 : a = x + 1 d 2 : b = x + 2 IN: {d 1,d 2, d 101, d 100 } x or y are global or parameters so we do not need a fake definition d 3 : x = a + 1 d 4 : b = y + 1 d 5 : y = b + 1

35 73

36 Uninitialized variables ENTRY d 100 : a = // no a or b if (Tcond1) d 1 : a = x + 1 d 2 : a = x + 2 IN: {d 1,d 2 } d 3 : a = a + 1 return a x is a global or parameter so we do not need a fake definition

37 75

38 Program analysis Compiler needs information Specific problem Devise flow analysis to compute information Let compiler use information to deal with specific problem 76