1 / 29

Redundant Expression Elimination

RE Elimination . CS640 GMU Fall 2009. 2. Redundant Expressions. DefinitionAn expression x op y is redundant at a point p if it has already been computed and no intervening operations redefined x or yOptimization for a redundant expressionPreserve the result of earlier computationsReplace subsequent evaluations with references to the saved valueSafetyNeed to prove that x op y is redundant TodayRedundancy elimination at different levels.

Jims
Download Presentation

Redundant Expression Elimination

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Redundant Expression Elimination CS640 Lecture 3 8.3, 8.68.3, 8.6

    2. RE Elimination CS640 GMU Fall 2009 2

    3. RE Elimination CS640 GMU Fall 2009 3 Redundant Expression Example An expression x op y is redundant at a point p if it has already been computed and no intervening operations redefine x or y m = 2*y*z t0 = 2*y t0 = 2*y m = t0*z m = t0*z n = 3*y*z t1 = 3*y t1 = 3*y n = t1*z n = t1*z o = 2*yz t2 = 2*y t2 = t0 o = t2-z o = t0-z

    4. RE Elimination CS640 GMU Fall 2009 4 Redundancy Elimination Tasks Need to prove that x op y is redundant Need to rewrite the code In basic blocks Using DAGs ? Using Value Numbering Beyond basic blocks Must consider all paths between the occurrences Dragon 6.1. 2, 8.5.2Dragon 6.1. 2, 8.5.2

    5. RE Elimination CS640 GMU Fall 2009 5 DAG Representations A dag (directed acyclic graph) for a basic block has the following labels for the nodes: Leaves are labeled by atomic operands Unique identifiers/numbers Interior nodes are labeled by operators/ids Edges pointing to operands Nodes can have multiple labels since they represent computed values x := y op z a := y op z ? Different approach but same resultDifferent approach but same result

    6. RE Elimination CS640 GMU Fall 2009 6 Generating DAGs from IR Process statements in a basic block sequentially: For statement i: x := y op z if y op z node exists, add x to the label for that node else add new node for op If y or z exist in the dag, point to existing locations, else add leaves for y and/or z and have the op node point to them Label the op node with x If x existed previously as a leaf, subscript that previous entry If x was previously associated with another interior node, remove that previous entry

    7. RE Elimination CS640 GMU Fall 2009 7 DAG Example 1 t0 := 2 * y m := t0 * z t1 := 3 * y n := t1 * z t1 := 2 * y o := t1 * z

    8. RE Elimination CS640 GMU Fall 2009 8 DAG Example 1 t0 := 2 * y m := t0 * z t1 := 3 * y n := t1 * z t1 := 2 * y o := t1 * z

    9. RE Elimination CS640 GMU Fall 2009 9 DAG Example 1 t0 := 2 * y m := t0 * z t1 := 3 * y n := t1 * z t1 := 2 * y o := t1 * z

    10. RE Elimination CS640 GMU Fall 2009 10 DAG Example 1 t0 := 2 * y m := t0 * z t1 := 3 * y n := t1 * z t1 := 2 * y o := t1 * z

    11. RE Elimination CS640 GMU Fall 2009 11 DAG Example 1 t0 := 2 * y m := t0 * z t1 := 3 * y n := t1 * z t1 := 2 * y o := t1 * z

    12. RE Elimination CS640 GMU Fall 2009 12 DAG Example 1 t0 := 2 * y m := t0 * z t1 := 3 * y n := t1 * z t1 := 2 * y o := t1 * z

    13. RE Elimination CS640 GMU Fall 2009 13 Generating code from DAGs Graph traversal t0 = 2 * y t1 = 3 * y n = t1 * z m = t0 * z o = m t1 = t0

    14. RE Elimination CS640 GMU Fall 2009 14 DAG Generation Problems Arrays Must equate all references to a given array since for a[i] and a[j], i may or may not be j x = a[i] a[j] = y z = a[i] /* multiple references to array a */ Pointers How can we determine where a pointer is pointing at in memory? *p = 0; /* increment subscript of every var that may get modified*/

    15. RE Elimination CS640 GMU Fall 2009 15 Redundancy Elimination Tasks Need to prove that x op y is redundant Need to rewrite the code In basic blocks Using DAGs Using Value Numbering ? Beyond basic blocks Must consider all paths between the occurrences For three addr codeFor three addr code

    16. RE Elimination CS640 GMU Fall 2009 16 Value Numbering Local (LVN) Goal: Group expressions that provably have the same value Associate a unique value number with each distinct value created or used within a block Two expressions have the same value number if and only if they are provably identical for all possible operands Classical way to fold constants and eliminate redundant expressions

    17. RE Elimination CS640 GMU Fall 2009 17 LVN Algorithm Construct a value table for a basic block A hash table that maps variables, constants, computed values to their value numbers Start with an empty value table For each operation o = o1 operator o2 in the block Get value numbers for the operands from a hash lookup in the value table Hash <operator,VN(o1),VN(o2)> to get a value number for o If o already had a value number, replace o with a reference; otherwise generate a new value number for o Record os value number into the value table If hashing behaves, the algorithm runs in linear time Minor issues Commutative operations Looks at VN of operand, not its name

    18. RE Elimination CS640 GMU Fall 2009 18 Example a = i + 1 b = i + 1 i = j if i + 1 goto L1 For variable a: hash <+, VN(i), VN(1)> get a new number 3

    19. RE Elimination CS640 GMU Fall 2009 19 Example a = i + 1 b = i + 1 i = j if i + 1 goto L1 For variable b: hash <+, VN(i), VN(1)> get an existing number 3

    20. RE Elimination CS640 GMU Fall 2009 20 Example a = i + 1 b = i + 1 i = j if i + 1 goto L1 VN(i) is changed to 4

    21. RE Elimination CS640 GMU Fall 2009 21 Example a = i + 1 b = i + 1 i = j if i + 1 goto L1

    22. RE Elimination CS640 GMU Fall 2009 22 Example a = i + 1 a = i + 1 b = i + 1 b = a i = j i = j if i + 1 goto L1 if i + 1 goto L1 a and b are given the same numbering, but not the condition expression for if-stmt

    23. RE Elimination CS640 GMU Fall 2009 23 Naming Issues

    24. RE Elimination CS640 GMU Fall 2009 24 Naming Issues

    25. RE Elimination CS640 GMU Fall 2009 25 Details Algebraic identities (a + 1 == 1 + a) Different results from DAG approach. x = 1 a = b + 1 c = b + x

    26. RE Elimination CS640 GMU Fall 2009 26 LVN Limitations a = i + 1 b = i + 1 i = j if i + 1 goto L1 LVN cannot eliminate redundant expression c=i+1 Why?

    27. RE Elimination CS640 GMU Fall 2009 27 Extensions to LVN Constant folding Add a bit that records when a value is constant Evaluate constant values at compile-time Replace with load immediate or immediate operand No stronger local algorithm Algebraic identities Must check (many) special cases Replace result with a copy operation Build a decision tree on operation Tests should be organized as a tree that first switches on the operatorTests should be organized as a tree that first switches on the operator

    28. RE Elimination CS640 GMU Fall 2009 28 Finding/Folding Constants i = 2 j = i * 2 k = i + 1

    29. RE Elimination CS640 GMU Fall 2009 29 Finding/Folding Constants i = 2 j = i * 2 k = i + 1

    30. RE Elimination CS640 GMU Fall 2009 30 Finding/Folding Constants i = 2 j = i * 2 k = i + 1 ? i = 2 j = 4 k = 3

    31. RE Elimination CS640 GMU Fall 2009 31 Example 2 a = i + 1 c = a + b d = 1 e = i + d f = d + 2

    32. RE Elimination CS640 GMU Fall 2009 32 Example 2 a = i + 1 c = a + b d = 1 e = i + d f = d + 2 a = i + 1 c = a + b d = 1 e = a f = 3

    33. RE Elimination CS640 GMU Fall 2009 33 Local Value Numbering Safety x op y has been computed: hash table starts empty Operands not redefined: mapping uses VN(x) and VN(y), not x and y With SSA, no value is ever redefined Profitability Assumes a copy is cheaper than an operation Loading constant cheaper than an operation Algebraic identities: do not include non-profitable ones Opportunity Linear scan basic block Exhaustive search for optimization opportunities

    34. RE Elimination CS640 GMU Fall 2009 34 Redundancy across Blocks Need to consider regions larger than basic blocks in CFG

    35. RE Elimination CS640 GMU Fall 2009 35 Redundancy across Blocks Superlocal value numbering(SVN): EBB

    36. RE Elimination CS640 GMU Fall 2009 36 Superlocal Value Numbering EBB: only the entry node can be join node

    37. RE Elimination CS640 GMU Fall 2009 37 Superlocal Value Numbering Idea Apply local method to each path in the EBB as if the set of blocks in a path were a single block AB, ACD, ACE Results from ancestors can be propagated to descendants A?C?D, A?C?E Use As hash-table to initialize Bs and Cs Efficiency Avoid re-analyzing common ancestors Stack-like scoped hash-table A, AB, A, AC, ACD, AC, ACE

    38. RE Elimination CS640 GMU Fall 2009 38 Redundancy across Blocks Rewriting: need to map VN to unique names Names across block boundaries

    39. RE Elimination CS640 GMU Fall 2009 39 Naming Issues Need a VN ? name mapping to handle kills Use the SSA name space Add subscripts to variable names for uniqueness Insert ?-functions at merge points to reconcile name spaces Details of SSA construction later in the course Principles Each name is defined by exactly one definition Principles Each name is defined by exactly one definition

    40. RE Elimination CS640 GMU Fall 2009 40 SSA Form SVN does not help block F or G How do we process join nodes?

    41. RE Elimination CS640 GMU Fall 2009 41 Larger Regions Problem of join nodes: multiple predecessors For block F, combine VN table of D and E? Merging states is expensive Fall back on whats known: both paths to F have a common prefix: {A,C} Dominator-based value numbering Use the VN table of IDOM(J) as the initial state for processing any join node J Start with the VN table produced by processing C for block F Will block D or E interfere? SSA ensures that D and E can add information to the value table, but they cannot invalidate it

    42. RE Elimination CS640 GMU Fall 2009 42 Dominator-based Value Numbering For join node F DOM(F) = {A, C} IDOM(F) = C Perform value numbering for F with the table we got by processing C as the initial state Join node G?

    43. RE Elimination CS640 GMU Fall 2009 43 Dominator-based Value Numbering DVN features Discover more redundancy(+) Little additional cost(+) Missing some opportunities(-) No values flow along back edges(-)

    44. RE Elimination CS640 GMU Fall 2009 44 Global Redundancy Elimination Global algorithm that processes an entire cycle of blocks potentially find more redundancy operations Neither SVN nor DVN can propagate information backward May need to process a block more than once Cannot perform code rewriting before analysis phase is finished Classic method: using data-flow analysis to compute the set of expressions that are available on entry to each block AVAIL analysis

    45. RE Elimination CS640 GMU Fall 2009 45 Avail Analysis An expression e is defined at point p if its value is computed at p p is called a definition site for e An expression e is killed at point p if one or more of its operands is defined at p p is called a kill site for e An expression e is available at a point p if every path leading to p contains a definition of e, and e is not killed between that definition and p An expression x op y is redundant at a point p if it has already been computed and no intervening operations redefine x or y

    46. RE Elimination CS640 GMU Fall 2009 46 Redundant Expressions

    47. RE Elimination CS640 GMU Fall 2009 47 Redundant Expressions

    48. RE Elimination CS640 GMU Fall 2009 48 Finding Global Redundancy Build CFG For each basic block b, compute local information: DEExpr(b) downward exposed expressions e ?DEExpr(b) if b evaluates e and none of es operands is re-defined after that evaluation Exprkill(b) expressions killed by definitions in the block Using local information, compute AVAIL_IN(b), AVAIL_OUT(b) over the entire CFG AVAIL_IN(b) is the set of available expressions on entry to block b

    49. RE Elimination CS640 GMU Fall 2009 49 Computing Local Information Assume a block B with operations o1, o2, , ok VARKILL[B] = {}; DEExpr[B]={} For i=k to 1 Assume oi is x=y op z Add x to VARKILL[B] If (y?VARKILL[B] && z?VARKILL[B]) add y op z to DEExpr[B] EXPRKILL[B]={} For each expression e in the procedure For each variable v?operands(e) If (v?VARKILL[B]) EXPRKLL[B] = EXPRKILL[B] ?{e}

    50. RE Elimination CS640 GMU Fall 2009 50 Example

    51. RE Elimination CS640 GMU Fall 2009 51 Example

    52. RE Elimination CS640 GMU Fall 2009 52 Computing Local Information Assume a block B with operations o1, o2, , ok VARKILL[B] = {}; DEExpr[B]={} For i=k to 1 Assume oi is x=y+z Add x to VARKILL[B] If (y?VARKILL[B] && z?VARKILL[B]) add y+z to DEExpr[B] EXPRKILL[B]={} For each expression e in the procedure For each variable v?operands(e) If (v?VARKILL[B]) EXPRKLL[B] = EXPRKILL[B] ?{e}

    53. RE Elimination CS640 GMU Fall 2009 53 Example

    54. RE Elimination CS640 GMU Fall 2009 54 Finding Global Redundancy Build CFG For each basic block b, compute local information: DEExpr(b) downward exposed expressions Exprkill(b) expressions killed by definitions in the block Using local information, compute AVAIL_IN(b), AVAIL_OUT(b) over the entire CFG AVAIL_IN(b) is the set of available expressions on entry to block b

    55. RE Elimination CS640 GMU Fall 2009 55 Computing Available Expressions For each block b Exprkill(b): set of expression killed in b DEExpr(b): set of downward exposed expressions AVAIL(b): set of expressions available on entry to b AVAIL_IN(b)=?x?pred(b)(AVAIL_OUT(x)) AVAIL_OUT(b)=DEExpr(b)?(AVAIL_IN(b)-Exprkill(b)) AVAIL_IN(b0) = This system of simultaneous equations forms a data-flow problem Solve it with a data-flow algorithm Available expressions = any expressions generated locally (DEExpr) plus any expressions available at the start of the block (from predecessor blocks) and not killed in the block Available expressions = any expressions generated locally (DEExpr) plus any expressions available at the start of the block (from predecessor blocks) and not killed in the block

    56. RE Elimination CS640 GMU Fall 2009 56 Iterative Algorithm for AVAIL AVAIL_IN(b0) = for i = 0 to k AVAIL_OUT(bi) = DEExpr(bi) while (changed) changed = false for i = 0 to k OldValue = AVAIL_IN(bi) AVAIL_IN(bi) =?x?pred(bi)(AVAIL_OUT(x)) AVAIL_OUT(bi) =DEExpr(bi)?(AVAIL_IN(bi)-Exprkill(bi)) If AVAIL(bi) <> OldValue then changed = true

    57. RE Elimination CS640 GMU Fall 2009 57 Example

    58. RE Elimination CS640 GMU Fall 2009 58 Global Redundancy Elimination Redundancy elimination based on AVAIL After computing AVAIL_IN[B] For ?B, ?e?AVAIL_IN[B], assign a unique name(e) to e At a definition site of e, if e is not available -- a new evaluation of e -- add a copy assignment: name(e) := e At a definition site of e, if e is available, replace (computation of) e by name(e)

    59. RE Elimination CS640 GMU Fall 2009 59 Example

    60. RE Elimination CS640 GMU Fall 2009 60 Example

    61. RE Elimination CS640 GMU Fall 2009 61 Comparing the Algorithms LVN/SVN/DVN: Local/Superlocal/Dominator-based value numbering GRE: global redundancy elimination

    62. RE Elimination CS640 GMU Fall 2009 62 Another GRE Example Pass 1

    63. RE Elimination CS640 GMU Fall 2009 63 Another GRE Example Pass 2

    64. RE Elimination CS640 GMU Fall 2009 64 Another GRE Example Pass 3

    65. RE Elimination CS640 GMU Fall 2009 65 GRE Based on AVAIL Safety Available expressions prove that the replacement value is current Transformation must ensure right name?value mapping Profitability Dont add any evaluations Add some copy operations Copies are inexpensive Copies can shrink or stretch live ranges

    66. RE Elimination CS640 GMU Fall 2009 66 Partial Redundancy

    67. RE Elimination CS640 GMU Fall 2009 67 Partial Redundancy Elimination An expression is partially redundant if it is available on some paths. Use standard data-flow techniques to figure out where to move the code Subsumes classical global common sub-expression elimination and code motion of loop invariants Used by many optimizing compilers Traditionally applied to lexically equivalent expressions With SSA support, applied to values as well

    68. RE Elimination CS640 GMU Fall 2009 68 Partial Redundancy Elimination May add a block to deal with critical edges Critical edge edge leading from a block with more than one successor to a block with more than one predecessor

    69. RE Elimination CS640 GMU Fall 2009 69 Partial Redundancy Elimination Code duplication to deal with redundancy

    70. RE Elimination CS640 GMU Fall 2009 70 Lazy Code Motion Redundancy: common expressions, loop invariant expressions, partially redundant expressions Desirable Properties: All redundant computations of expressions that can be eliminated with code duplication are eliminated. The optimized program does not perform any computation that is not in the original program execution Expressions are computed at the latest possible time.

    71. RE Elimination CS640 GMU Fall 2009 71 Lazy Code Motion Solve four data-flow problems that reveal the limit of code motion AVAIL: available expressions ANTI: anticipated expression EARLIEST: earliest placement for expressions LATER: expressions that can be postponed Compute INSERT and DELETE sets based on the data-flow solutions for each basic block They define how to move expressions between basic blocks

    72. RE Elimination CS640 GMU Fall 2009 72 Lazy Code Motion

    73. RE Elimination CS640 GMU Fall 2009 73 Lazy Code Motion

    74. RE Elimination CS640 GMU Fall 2009 74 Local Information For each block b, compute the local sets: DEExpr: an expression is downward-exposed (locally generated) if it is computed in b and its operands are not modified after its last computation UEExpr: an expression is upward-exposed if it is computed in b and its operands are not modified before its first computation NotKilled: an expression is not killed if none of its operands is modified in b f = b + d a = b + c d = a + e

    75. RE Elimination CS640 GMU Fall 2009 75 Local Information What do they imply? DEExpr:e ? DEExpr(b) ? evaluating e at the end of b produces the same result as evaluating it at the original position in b UEExpr:e ? UEExpr(b) ? evaluating e at the entry of b produces the same result as evaluating it at the original position in b NotKilled: e ? NotKilled(b) ? evaluating e at either the start or end of b produces the same result as evaluating it at the original position f = b + d a = b + c d = a + e

    76. RE Elimination CS640 GMU Fall 2009 76 Example

    77. RE Elimination CS640 GMU Fall 2009 77 Global Information Availability AvailIn(n0) = AvailIn(b)=?x?pred(b)AvailOut(x), b ? n0 AvailOut(b)=DEExpr(b)?(AvailIn(b)? NotKilled(b)) Initialize AvailIn and AvailOut to be the set of expressions for all blocks except for the entry block n0 Interpreting Avail sets e ? AvailOut(b) ? evaluating e at end of b produces the same value for e as its most recent evaluation, no matter whether the most recent one is inside b or not AvailOut tells the compiler how far forward e can move

    78. RE Elimination CS640 GMU Fall 2009 78 Example: Avail

    79. RE Elimination CS640 GMU Fall 2009 79 Global Information Anticipability Expression e is anticipated at a point p if e is certain to be evaluated along all computation path leaving p before any re-computation of es operands AntOut(nf) = AntOut(b)=?x?succ(b)AntIn(x), b ? nf AntIn(b)=UEExpr(b)?(AntOut(b)?NotKilled(b)) Initialize AntOut to be the set of expressions for all blocks except for the exit block nf Interpreting Ant sets e ? AntIn(b) ? evaluating e at start of b produces the same value for e as evaluating it at the original position(later than start of b) with no additional overhead AntIn tells the compiler how far backward e can move No additional overhead: no redundancyNo additional overhead: no redundancy

    80. RE Elimination CS640 GMU Fall 2009 80 Example: Ant

    81. RE Elimination CS640 GMU Fall 2009 81 Example: Avail and Ant

    82. RE Elimination CS640 GMU Fall 2009 82 Placing Expressions Earliest placement For an edge <i,j> in CFG, an expression e is in Earliest (i,j) if and only if the computation can legally move to <i,j> and cannot move to any earlier edge EARLIEST(i,j) = AntIn(j) ? AvailOut(i)? ??(NotKilled(i) ? AntOut(i)) e ? AntIn(j): we can move e to the start of block j without generating un-necessary computation e ? AvailOut(i): no previous computation of e is available from the exit of i: if such an e exists, it would make the computation on <i,j> redundant e ? (Killed(i) ?AntOut(i)): we cannot move e further upward e ? Killed(i): e cannot be moved to an edge <x,i> with the same value e ? AntOut(i): there is another path starting with edge <i,x> along which e is not evaluated with the same value

    83. RE Elimination CS640 GMU Fall 2009 83 EARLIEST(i,j) = AntIn(j) ? AvailOut(i)??(NotKilled(i) ? AntOut(i))

    84. RE Elimination CS640 GMU Fall 2009 84 EARLIEST(i,j) = AntIn(j) ? AvailOut(i)??(NotKilled(i) ? AntOut(i))

    85. RE Elimination CS640 GMU Fall 2009 85 Placing Expressions Earliest placement For an edge <i,j> in CFG, an expression e is in Earliest (i,j) if and only if the computation can legally move to <i,j> and cannot move to any earlier edge EARLIEST(i,j) = AntIn(j) ? AvailOut(i)? ??(NotKilled(i) ? AntOut(i)) EARLIEST(n0,j) = AntIn(j) ? AvailOut(n0)? We can never move e before entry point n0: the last term is ignored n0 must be the dummy entry point

    86. RE Elimination CS640 GMU Fall 2009 86 Postpone Evaluations We want to delay the evaluation of expressions as long as possible Motivation: save register usage There is a limit to this delay Not past the use of the expression Not so far that we end up computing an expression that is already evaluated

    87. RE Elimination CS640 GMU Fall 2009 87 Placing Expressions Later (than earliest) placement An expression e is in LaterIn(k) if evaluation of e can be moved through entry to k without losing any benefit e ? LaterIn(k) if and only if every path that reaches k includes an edge <p,q> s.t. e? EARLIEST(p,q), and the path from q to k neither kills e nor uses e LaterIn(j) = ? i?pred(j)LATER(i,j), j?n0? LaterIn(n0) = LATER(i,j) = (EARLIEST(i,j) ? LaterIn(i))? UEExpr(i), i?pred(j) ? An expression e is in LATER(i,j) if evaluation of e can be moved (postponed) to CFG edge <i,j> e ? LATER(i,j) if <i,j> is its earliest placement, or it can be moved to the entry of i and there is no evaluation(use) of e in block i Postponable dragon from the entry of iPostponable dragon from the entry of i

    88. RE Elimination CS640 GMU Fall 2009 88 Example: LATER

    89. RE Elimination CS640 GMU Fall 2009 89 Rewriting Code Insert set for each CFG edge The computations that LCM should insert on that edge Insert(i,j) = LATER(i,j) ? LaterIn(j) ? e ? Insert(i,j) means an evaluation of e should be added between block i and block j Three possible places to add Delete set for each block The computations that LCM should delete from that block Delete(i) = UEExpr(i) ? LaterIn(i), i?n0? ? The first computation in i is redundant

    90. RE Elimination CS640 GMU Fall 2009 90 Example: INSERT & DELETE

    91. RE Elimination CS640 GMU Fall 2009 91 Insert set for each CFG edge The computations that LCM should insert on that edge Insert(i,j) = LATER(i,j) ? LaterIn(j) ? If i has only one successor, insert computations at the end of i If j has only one predecessor, insert computations at the entry of j Otherwise, split the edge and insert the computations in a new block between i and j Delete set for each block The computations that LCM should delete from that block Delete(i) = UEExpr(i) ? LaterIn(i), i?n0? ? The first computation in i is redundant: remove it Rewriting Code

    92. RE Elimination CS640 GMU Fall 2009 92 Inserting Code Evaluation placement for x ? INSERT(i,j) Three cases |succs(i)| = 1 ? insert at end of i |succs(i)| > 1, but |preds(j)| = 1? insert at start of j |succs(i)| > 1, & |preds(j)| > 1 ? create new block in <i,j> for x

    93. RE Elimination CS640 GMU Fall 2009 93 Example: INSERT & DELETE

    94. RE Elimination CS640 GMU Fall 2009 94 Example: Rewriting

    95. RE Elimination CS640 GMU Fall 2009 95 Lazy Code Motion Step1: identify the limit of code motion Available expressions Anticipated expressions Step 2: move expression evaluation up Later ones may become redundant Step 3: move expression evaluation down Delay evaluation to minimize register lifetime Step 4: rewrite code

    96. RE Elimination CS640 GMU Fall 2009 96 Summary Redundant expression elimination Local algorithms DAG, local value numbering Extending basic block to larger regions Extended BB: superlocal VN Join nodes: dominator-based VN SSA: mapping value numbers to unique names Propagate information along forward edges Global elimination for the whole procedure Iterative AVAIL analysis Information propagated backward Lessons Safety and profitability Discovering opportunities + transforming code

    97. RE Elimination CS640 GMU Fall 2009 97 Lazy Code Motion A powerful algorithm Finds different forms of redundancy in a unified framework Subsumes loop invariant code motion and common expression elimination Data-flow analysis Composes several simple data-flow analyses to produce a powerful result

    98. RE Elimination CS640 GMU Fall 2009 98 Next Lecture Topic Iterative data-flow analysis Move information through the control flow graph References EAC Ch9 Dragon Ch9.2-9.3

More Related