


Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Solutions to practice problems related to compiler optimizations, including optimization techniques, control flow analysis, reaching definitions, live variables, and available expressions. It covers concepts such as peephole, local, global, and interprocedural optimizations, depth-first and postorder traversals, and data-flow lattices.
Typology: Exams
1 / 4
This page cannot be seen from the preview
Don't miss anything!



(a) How can compiler transformations improve a pro- gram? By reducing program size or number of instructions executed, taking advantage of redundant computa- tions, customizing general purpose code, or undo- ing high-level abstractions. (b) What does the compiler need to consider when ap- plying optimizations? Safety, profitability, and applicability. (c) What are the different scopes of compiler optimiza- tions? What are the tradeoffs when considering what scope of optimizations to use? Peephole, local, global, or interprocedural. The ba- sic tradeoff is more complexity and compile time for optimizations with greater scope.
Consider the following code.
(1) a := 1 (2) b := f + a (3) c := a (4) d := f + a (5) e := f + c (6) f := b (7) g := f + a
(a) Build a DAG for the code.
Note that assignment gives a node multiple labels, and may require renaming variables.
For the following problems, consider this code:
(a) What are the basic blocks? B1 = { S1, S2 } B2 = { S3, S4, S5 } B3 = { S6, S7 } B4 = { S8, S9, S10 } B5 = { S11, S12, S13 } B6 = { S14, S15 } (b) What is the control flow graph?
B
B
B
B
B
B
(c) Depth-first order selects nodes in the order they are visited (start by visiting the root node) and then recursively visiting every child of each node (if the child has not been visited before). Note that the order in which children are visited is random. What are all the possible results of depth-first traver- sal on the control flow graph? B1, B2, B3, B4, B5, B B1, B2, B5, B6, B3, B B1, B2, B3, B5, B6, B (d) Using depth-first order, is it possible to visit a child before its parent? For which depth-first ordering(s) of the control flow graph does this occur? B1, B2, B5, B6, B3, B
(e) Postorder selects nodes (starting from root) after visiting every child of that node (if the child has not been visited before). Note that the order in which children are visited is random. What are all the possible results of Postorder traver- sal for the control flow graph? B6, B5, B4, B3, B2, B B4, B6, B5, B3, B2, B (f) Reverse Postorder simply reverses the node order- ing found by a Postorder traversal of the graph. What are the possible Reverse Postorder traver- sals of the control flow graph? B1, B2, B3, B4, B5, B B1, B2, B3, B5, B6, B (g) Using Reverse Postorder, is it possible to visit a child before its parent? Why or why not? Yes, because not all parents can be visited first if there are loops (cycles) in the control flow graph.
Reaching definitions (RD) for a point in the program p is defined as the set of definitions of a variable for which there is some path from the definition to p with no other definition of that variable. Calculate reaching definitions for the code in the control-flow graph prob- lem.
(a) What is the dataflow equation for RD? RD(b) =
x∈pred(b)(GEN(x)^ ∪^ (RD(x)^ −^ KILL(x))) (b) In what direction is RD calculated? I.e., does in- formation flow forwards or backwards in the CFG? Forwards. (c) Calculate GEN, KILL for each basic block. Note: For reaching definitions, we append to each variable definition its location to distinguish be- tween multiple definitions to the same variable.
Block GEN KILL B1 a1,b2 a1,b2,b11,a14,b B2 c3,d4 c3,d4,d6,d B3 d6 d4,d6,d B4 d8,e9 d4,d6,d8,e9,e B5 b11,e12 b2,e9,b11,e12,b B6 a14,b15 a1,b2,b11,a14,b
(d) What is a good initial value for RD for each basic block? RD for each basic block is initialized to ∅ (no reach- ing definitions). (e) Solve the data-flow equations in reverse Postorder. Show your work.
Solving the data flow equations in reverse postorder (B1,B2,B3,B4,B5,B6), we get the following (IN, OUT initially all set to ∅):
Block Data Pass1 Pass B1 IN ∅ ∅ OUT a1,b2 a1,b B2 IN a1,b2 a1,b2,c3,d4,d6,b11,e OUT a1,b2,c3,d4 a1,b2,c3,d4,b11,e B3 IN a1,b2,c3,d4 a1,b2,c3,d4,d8,e9,b11,e OUT a1,b2,c3,d6 a1,b2,c3,d6,e9,b11,e B4 IN a1,b2,c3,d6 a1,b2,c3,d6,e9,b11,e OUT a1,b2,c3,d8,e9 a1,b2,c3,d8,e9,b B5 IN a1,b2,c3,d4,d6 a1,b2,c3,d4,d6,e9,b11,e OUT a1,c3,d4,d6,b11,e12 a1,c3,d4,d6,b11,e B6 IN a1,c3,d4,d6,b11,e12 a1,c3,d4,d6,b11,e OUT c3,d4,d6,e12,a14,b15 c3,d4,d6,e12,a14,b
(a) We define LV(b) for a basic block b to be the set of live variables at the end of b. What is the dataflow equation for LV?
LV(b) =
x∈succ(b)(GEN(x)^ ∪^ (LV(x)^ −^ KILL(x)))
(b) In what direction is LV calculated? I.e., does in- formation flow forwards or backwards in the CFG? Backwards. (c) Show GEN, KILL for each basic block.
Block GEN KILL B1 ∅ a,b B2 a,b c,d B3 b,d d B4 a,b,e d,e B5 a,b,c b,e B6 b,d a,b (d) What is a good initial value for LV for each basic block? LV for each basic block is initialized to ∅ (no live variables). This is an optimistic assumption for dead code elimination, but also accurately reflects the fact that no variables are live at the end of the program. (e) Solve the data-flow equations in rPostorder. Show your work. Solving the data flow equations in postorder
Since ∧ is associative, we find a ∧ (b ∧ c) = (a ∧ b) ∧ c = a ∧ c.
But since we also have a ∧ (b ∧ c) = a, this implies a ∧ c = a.
By definition of ≤, this implies a ≤ c.
(b) Show that a ≤ (b ∧ c) implies a ≤ b
First, we show (b ∧ c) ≤ b.
By definition of ≤, this is true if b ∧ (b ∧ c) = b ∧ c.
Since ∧ is associative, we prove it using b∧(b∧c) = (b ∧ b) ∧ c = b ∧ c.
Now combining a ≤ (b ∧ c) and (b ∧ c) ≤ b gives us a ≤ b, using the solution to the previous problem.
(a) When estimating each of the following sets, tell whether too-large or too-small estimates are con- servative. Explain your answer in terms of the in- tended use of information. i. Available expressions Too-small estimates are conservative (⊥ = ∅). Common subexpression elimination would not replace some expressions if the estimate is too small, but the answer would be still correct. In comparison, performing CSE when an ex- pression is not available may yield incorrect results. ii. Reaching definitions Too-large estimates are conservative (⊥ = { all copy statements } ). Copy propagation would be restricted if the es- timate of copy statements reaching a point is too large, but the result would still be correct. In comparison, estimating too few copy state- ments reach a given point may enable copy propagation when the right-hand side of a miss- ing copy statement differs from the right-hand side of the copy statements found, yielding in- correct results. iii. Live variables Too-large estimates are conservative (⊥ = all variables). Dead code elimination uses live variable infor- mation to eliminate definitions for variables that are no longer live. Assuming all variables were live would cause dead code elimination to not make any changes to code. (b) What properties are necessary to ensure an itera- tive data-flow analysis framework terminates? The dataflow problem must be monotonic, I.e., f (x ∧ y) ≤ f (x) ∧ f (y). All chains (sequences of less-than orderings) in the lattice must also have finite length (true for any lattice with finite height).
(c) What properties are necessary to ensure an itera- tive data-flow analysis framework terminates with the meet-over-all-paths solution? The dataflow problem must be distributive. I.e., f (x ∧ y) = f (x) ∧ f (y).