Instruction Selection via Tree-Pattern Matching Comp 412

Transcription

1 COMP FALL 017 Instruction Selection via TreePattern Matching Comp source code IR Front End Optimizer Back End IR target code Copyright 017, Keith D. Cooper & Linda Torczon, all rights reserved. Students enrolled in Comp at Rice University have explicit permission to make copies of these materials for their personal use. Faculty from other educational institutions may use these materials for nonprofit educational purposes, provided this copyright notice is preserved. Chapter 11 in EaC3e

2 Automatic Generation of Instruction Selectors We want to automate generation of instruction selectors (as with parsers & scanners) source code IR Front End Optimizer Back End IR target code machine description BackEnd Generator Tables Hardcoded Pattern Matcher Pattern Matching Engine Selector Descriptionbased retargeting COMP, Fall 017 1

3 Treepattern matching We want to match tree patterns with tree IR Goal is to tile the AST with patterns for machine operations A tiling is collection of <node, pattern > pairs node is a subtree in the tree representation of the code (AST) pattern is a tree describing an instruction sequence <node, pattern> means that pattern could implement a subtree at node A tiling implements an AST if it covers every node in the AST & the overlap between any two trees occurs at a single node <node, pattern> Î tiling means that the root of node is also covered by a leaf in another pattern tree in the tiling, unless node is the root of the AST Where two pattern trees overlap, they must be compatible; that is, they expect the value in the same location (They have the same type.) COMP, Fall 017 9

4 A Tiling of Our Example Tree (Conceptual) Each tile corresponds to a sequence of operations Tile 6 Tile 1 Tile 5 Tile Emitting those operations in an appropriate order implements the tree. Tile Tile 3 Tile numbers correspond to a postorder traversal of the AST. COMP, Fall

5 Generating Code from the Tiled Tree Once the compiler has the tiled tree, it must generate code for the tiles Postorder treewalk, with nodedependent visitation order Right child of before its left child For arithmetic, might impose most demanding subtree first rule (Sethi) Emit code sequence for tiles, in traversal order Tie boundaries together with names (e.g., VRs) Tile 6 uses registers produced by tiles 1 & 5 Code template for tile 6 is store r tile5 Þ r tile1 Can incorporate a real allocator or increment a NextRegister counter Tile 6 Tile 1 Tile 5 COMP, Fall

6 So, What s Hard About This? Finding the matches to tile the tree The compiler writer specifies a mapping from AST to operations Provide a set of rewrite rules Rewrite rules describe the AST Encode tree syntax, in linear prefix form Each rule also has a code template and a cost Tile 1 Tile 6 Tile 5 Tile Tile Tile 3 The compiler writer produces the mapping. Tools turn the mapping into a working instruction selector. Our Tiling Example apparently derived by an oracle Let s look at a set of rules to map our lowlevel AST into ILOC COMP, Fall 017

7 Building a Rule For load How do we build rules for the matcher? Consider a load from memory Tree ILOC Rule Reg load ri => rj Reg j (Reg i ) COMP, Fall 017 Rules are defined over types & operators 13

8 Building a Rule For load What about an address computation? Tree ILOC Rule loadai ri, cj => rk Reg k ((Reg i, j )) Reg The rule for loadai incorporates both the load () and the addition performed in the addressing hardware. Of course, it should have a commutative variant Reg k (( j,reg i )) COMP, Fall 017 1

9 Building a Rule For load What about an address computation? Tree ILOC Rule loadao ri, rj => rk Reg k ((Reg i,reg j )) Reg Reg The rule for loadao is similar to the rule for loadai Difference lies in the type of the operands No need for a commutative variant Reg Reg Reg The rules for loadai and loadao COMP, Fall 017 each incorporate two operators. 15

10 The Big Simplification To make the algorithm manageable, we will assume (wlog): Each rule implements at most one operator Eliminates complex rules that match multiple nodes Reg ( (Reg 1, )) cost: 1 (rule for loadai) Instead, we break such rules into single operator rules & distribute the cost Reg (T 1 ) cost: 1 T 1 (Reg 1, ) cost: 0 Could use costs of ½ & ½, or ¾ and ¼, or... Use a unique LHS or class or type to tie them together Multiple operations per rule means algorithm must look at combinations Leads to significant complications (solvable, but why bother?) Assume each operator takes 0, 1, or operands Allows us to phrase the patternmatching problem as a simple treewalk COMP, Fall 017

11 The Big Simplification To make the algorithm manageable, we will assume (wlog): Each rule implements at most one operator Eliminates complex rules that match multiple nodes Reg ( (Reg 1, )) cost: 1 (rule for loadai) Instead, we break such rules into single operator rules & distribute the cost Reg (T 1 ) cost: 1 T 1 (Reg 1, ) cost: 0 Use a unique LHS or class or type to tie them together Could use costs of ½ & ½, or ¾ and ¼, or... The Critical Point A set of single operator rules like this one achieves the same result as the multiple operator rule, given appropriate costs for the set Same cost, same result, same algorithmic choices Does increase the number of LHS names (labels) COMP, Fall

12 The Big Simplification Each rule implements at most one operator One more point: The simplification means that all tiles are small Cover a node and its children (if any) Our earlier drawings showed large tiles Tile 6 Tiles and 3 are multioperator tiles Tile has 3 operators Tile 3 has operators We can (and will) tile them with single operator tiles Tile 1 Tile Tile 5 Tile Tile 3 Our Tiling Example apparently derived by an oracle COMP, Fall

13 Rewrite rules: LL Integer AST into ILOC Rule Cost Template 0 Goal Goal Stmt 0 1 Goal Stmt 0 Stmt (Reg 1, Reg ) 1 store r Þ r 1 3 Stmt (T1, Reg ) 1 storeao r 3 Þ T1.r 1,T1.r Stmt (T, Reg ) 1 storeai r 3 Þ T.r,T.n 5 Reg (Reg 1 ) 1 load r 1 Þ r new 6 Reg (T1) 1 loadao T1.r 1,T1.r Þ r new 7 Reg (T) 1 loadai T.r,T.n Þ r new 8 Reg (Reg 1,Reg ) 1 add r 1,r Þ r new 9 Reg (Reg 1,T3 ) 1 addi r 1,T3 Þ r new 10 Reg (T3 1,Reg ) 1 addi r,t3 Þ r new 11 Reg (Reg 1,Reg ) 1 sub r 1,r Þ r new Reg (Reg 1,T3 ) 1 subi r 1,T3 Þ r new 13 Reg (T3 1,Reg ) 1 rsubi r,t3 Þ r new COMP, Fall 017 EaC3e 19

14 Rewrite rules: LL Integer AST into ILOC (part II) Rule Cost Template 1 Reg (Reg 1,Reg ) 1 mult r 1,r Þ r new 15 Reg (Reg 1,T3 ) 1 multi r 1,T3 Þ r new Reg (T3 1,Reg ) 1 multi r,t3 Þ r new 17 Reg CON 1 1 loadi C 1 Þ r new 18 Reg 1 1 loadi N 1 Þ r new 19 Reg 1 Þ r new1 loadai r Þ r new 0 Reg 1 0 // is already in a register 1 T1 (Reg 1,Reg ) 0 // reg reg for loadao T (Reg 1, T3) 0 // reg con for loadai 3 T (T3, Reg 1 ) 0 // con reg for loadai T3 1 0 // con for immed arith ops And this rule set is still overly simplistic Size of the rule set is driven primarily by the AST (not the ISA). COMP Adding, rules Fall can 017 improve the quality of the generated code, EaC3e 0

15 Tiling the Tree Tile(n) if n is a leaf Match(n,) { rules that implement n} else if n is a unary node Tile(child(n)) Match(n,) Ø for each rule r where op(r) = op(n) if (child(r) & child(n) are compatible) then add r to Match(n,class(r)) else if n is a binary node Tile (left(n)) Tile (right(n)) Match(n,) Ø for each rule r where op(r) = op(n) if (left(r) & left(n) are compatible) and (right(r) & right(n) are compatible) then add r to Match(n,class(r)) Match a leaf Match unary nodes against unary rules Match binary nodes against binary rules COMP, Fall 017 1

16 Tiling the Tree Tile(n) if n is a leaf Match(n,) { rules that implement n} else if n is a unary node Tile(child(n)) Match(n,) Ø for each rule r where op(r) = op(n) if (child(r) & child(n) are compatible) then add r to Match(n,class(r)) else if n is a binary node Tile (left(n)) Tile (right(n)) Match(n,) Ø for each rule r where op(r) = op(n) if (left(r) & left(n) are compatible) and (right(r) & right(n) are compatible) then add r to Match(n,class(r)) For a leaf, Match can be precomputed: Stmt T1 T T3 Reg 18 The Match Entry for For unary or binary nodes, Tile() first recurs on the subtree(s) and then finds compatible rules. Search the rules that match op(n) Rules are compatible if the classes of the children match appropriately Accumulate matches in Match(n,) COMP, Fall 017

17 Instruction Selection via TreePattern Matching Our Example: is a leaf, and {Reg: 0} is its precomputed entry. Stmt T1 T T3 Reg No column for Goal a: at b: at 8 (call by ref) c: at COMP, Fall 017 3

18 Instruction Selection via TreePattern Matching Our Example: is a leaf, and {T3:, Reg: 18} is its precomputed entry. Stmt T1 T T3 Reg a: at b: at 8 (call by ref) c: at COMP, Fall 017

19 Instruction Selection via TreePattern Matching Our Example: Rules 8, 9, 10, 1,, & 3 implement addition. Four are compatible. 3 Stmt T1 T T3 Reg , 9 a: at b: at 8 (call by ref) c: at COMP, Fall 017 5

20 Instruction Selection via TreePattern Matching Our Example: is a leaf, and {Reg: 0} is its precomputed entry. Stmt T1 T T3 Reg , 9 0 a: at b: at 8 (call by ref) c: at COMP, Fall 017 6

21 Instruction Selection via TreePattern Matching Our Example: is a leaf, and {T3:, Reg: 18} is its precomputed entry. Stmt T1 T T3 Reg , a: at b: at 8 (call by ref) c: at 5 COMP, Fall 017 7

22 Instruction Selection via TreePattern Matching Our Example: Rules 11,, & 13 implement subtraction. 11 & match. Stmt T1 T T3 Reg , , a: at b: at 8 (call by ref) c: at 6 COMP, Fall 017 8

23 Instruction Selection via TreePattern Matching Our Example: Stmt T1 T T3 Reg Rules 5, 6, & 7 all implement. Only 5 matches , , a: at b: at 8 (call by ref) c: at COMP, Fall 017 9

24 Instruction Selection via TreePattern Matching Our Example: Rules 5, 6, & 7 all implement. Only 5 matches.. 8 Stmt T1 T T3 Reg , , a: at b: at 8 (call by ref) c: at COMP, Fall

25 Instruction Selection via TreePattern Matching Our Example: Stmt T1 T T3 Reg is a leaf, and {T3:, Reg: 8} is its precomputed entry , , a: at b: at 8 (call by ref) c: at COMP, Fall

26 Instruction Selection via TreePattern Matching Our Example: Stmt T1 T T3 Reg is a leaf, and {Reg: 19} is its precomputed entry , , a: at b: at 8 (call by ref) c: at 10 COMP, Fall 017 3

27 Instruction Selection via TreePattern Matching Our Example: is a leaf, and {T3:, Reg: 18} is its precomputed entry. a: at b: at 8 (call by ref) c: at COMP, Fall Stmt T1 T T3 Reg , ,

28 Instruction Selection via TreePattern Matching Our Example: Rules 8, 9, 10, 1,, & 3 implement addition. Four are compatible. a: at b: at 8 (call by ref) c: at COMP, Fall Stmt T1 T T3 Reg , , , 9

29 Instruction Selection via TreePattern Matching Our Example: Rules 5, 6, & 7 all implement. All three are compatible. a: at b: at 8 (call by ref) c: at COMP, Fall Stmt T1 T T3 Reg , , , , 6, 7

30 Instruction Selection via TreePattern Matching Our Example: Rules 1, 15, & all implement multiplication. Two are compatible with subtree matches. a: at b: at 8 (call by ref) c: at 1 COMP, Fall Stmt T1 T T3 Reg , , , , 6, 7 1 1,

31 Instruction Selection via TreePattern Matching Our Example: Rules 11,, & 13 all implement subtraction. Only 11 is compatible with two Reg labels. a: at b: at 8 (call by ref) c: at 15 COMP, Fall Stmt T1 T T3 Reg , , , , 6, 7 1 1, 15 11

32 Instruction Selection via TreePattern Matching Our Example: Rules, 3, & all implement. All three are compatible with matches from node 3. a: at b: at 8 (call by ref) c: at COMP, Fall 017 Stmt T1 T T3 Reg , , , , 6, 7 1 1, 15 11, 3, 38

33 Instruction Selection via TreePattern Matching 1 Code selection should be guided by costs When choice exists, take the lowcost choice 3 a: at b: at (call by ref) v: at COMP, Fall Stmt T1 T T3 Reg , , , , 6, 7 1 1, 15 11, 3, 39

34 Instruction Selection via TreePattern Matching 1 Code selection should be guided by costs When choice exists, take the lowcost choice 3 a: at b: at (call by ref) v: at COMP, Fall The lowcost choice often requires context Stmt T1 T T3 Reg , , , , 6, 7 1 1, 15 11, 3, 0

35 Instruction Selection via TreePattern Matching Focus on subtree rooted at node 13 What do the options & costs suggest? 3 1 a: at b: at (call by ref) v: at Stmt T1 T T3 Reg , , , , 6, 7 1 1, COMP, Fall 017, 3,

36 Instruction Selection via TreePattern Matching Focus on subtree rooted at node 13 What do the options & costs suggest? Rule for 13 Sequence Cost 5 <19,18,8,5> 9 5 <19,,9,5> 8 6 <19,18,1,6> 8 7 <19,,,7> 7 Stmt T1 T T3 Reg , , , , 6, 7 1 1, and COMP their, commutative Fall 017 variants, 3,

37 Instruction Selection via TreePattern Matching Focus on subtree rooted at node 13 What do the options & costs suggest? loadi loadai load 8 add loadi Rule for 13 Sequence Cost 5 <19,18,8,5> 9 5 <19,,9,5> 8 6 <19,18,1,6> 8 7 <19,,,7> 7 Generated Code for <19,18,8,5> Þ r i loadai r i, Þ r j loadi Þ r k add r j, r k Þ r m load r m Þ r n Stmt T1 T T3 Reg , , , , 6, 7 1 1, COMP, Fall 017, 3, 3

38 Instruction Selection via TreePattern Matching Focus on subtree rooted at node 13 What do the options & costs suggest? loadi loadai load addi Rule for 13 Sequence Cost 5 <19,18,8,5> 9 5 <19,,9,5> 8 6 <19,18,1,6> 8 7 <19,,,7> 7 Generated Code for <19,,9,5> Þ r i loadai r i, Þ r j addi r j, Þ r k load r k Þ r m Stmt T1 T T3 Reg , , , , 6, 7 1 1, COMP, Fall 017, 3,

39 Instruction Selection via TreePattern Matching Focus on subtree rooted at node 13 What do the options & costs suggest? loadi loadai 6 loadao loadi Rule for 13 Sequence Cost 5 <19,18,8,5> 9 5 <19,,9,5> 8 6 <19,18,1,6> 8 7 <19,,,7> 7 Generated Code for <19,18,1,6> Þ r i loadai r i, Þ r j loadi Þ r k loadao r j, r k Þ r m Stmt T1 T T3 Reg , , , , 6, 7 1 1, COMP, Fall 017, 3, 5

40 Instruction Selection via TreePattern Matching Focus on subtree rooted at node 13 What do the options & costs suggest? loadai loadi loadai Rule for 13 Sequence Cost 5 <19,18,8,5> 9 5 <19,,9,5> 8 6 <19,18,1,6> 8 7 <19,,,7> 7 Generated Code for <19,18,1,6> Þ r i loadai r i, Þ r j loadai r j, Þ r k <19,,,7> is clearly the low cost sequence. Stmt T1 T T3 Reg , , , , 6, 7 1 1, COMP, Fall 017, 3, 6

41 Instruction Selection via TreePattern Matching What about node? Same kinds of choices play out here 3 Rules for Sequence Total Cost <0,18,8,, > 5 cost(node 15) <0,,9,, > cost(node 15) 3 <0,18,1,, 3,> cost(node 15) <0,,,, > 3 cost(node 15) 15 The only option for node 15 is a REG Stmt T1 T T3 Reg , , , , 6, 7 1 1, COMP, Assumes Fall 017 node 15 is in a Reg already, 3, 7

42 Instruction Selection via TreePattern Matching What about node 1? Costs should drive selection of multi over mult The only option for node 13 is a REG Rules for 1 Sequence Total Cost 1 <18,, 1> cost(node 13) <,,> 1 cost(node 13) Assumes node 1 is in a Reg already Stmt T1 T T3 Reg , , , , 6, 7 1 1, COMP, Fall 017, 3, 8

43 Tiling the Tree Adding cost to the algorithm Tile(n) if n is a leaf Match(n,) { rules that implement n} else if n is a unary node Tile(child(n)) Match(n,) Ø for each rule r where op(r) = op(n) if (child(r) & child(n) are compatible) then add r to Match(n,class(r)) else if n is a binary node Tile (left(n)) Tile (right(n)) Match(n,) Ø for each rule r where op(r) = op(n) if (left(r) & left(n) are compatible) and (right(r) & right(n) are compatible) then add r to Match(n,class(r)) Why track all matches in a category when the algorithm will only use the lowcost match? Instead, the algorithm can test each new match against the previous lowcost match & keep the least expensive option. No accounting for costs Keeps all matches COMP, Fall 017 9

44 Tile() With Costs Keep only low cost matches in each category (LHS symbol) Keep track of both rule and cumulative cost At each possible new match, compute cost of new match and compare Simplifies data structures Two integers vs. a set Changes initializations Can precompute leaves, as before Tile(n) / n is a node in an AST / if nisaleafnodethen Match(n, ).rule { lowcost rule that matches n,ineachclass} Match(n, ).cost { corresponding cost } else if nisaunarynodethen Tile(child(n)) Match(n,).rule invalid Match(n,).cost largest integer for each rule r where operator(r) = operator(n) if (child(r), child(n)) are compatible then NewCost RuleCost(r) Match(child(n),class(child(r))).cost if (Match(n,class(r)).cost > NewCost) then Match(n,class(r)).rule r Match(n,class(r)).cost NewCost else if nisabinarynodethen Tile(left(n)) Tile(right(n)) Match(n,).rule invalid Match(n,).cost largest integer for each rule r where operator(r) = operator(n) if (left(r), left(n)) and (right(r), right(n)) are compatible then NewCost RuleCost(r) Match(left(n), class(left(r))).cost Match(right(n), class(right(r))).cost if (Match(n,class(r)).cost > NewCost) then Match(n,class(r)).rule r Match(n,class(r)).cost NewCost FIGURE 11.9 Compute LowCost Matches to Tile an AST COMP, Fall

45 Tile() With Costs We could precompute more Entire inner loop is really a lookup on operator & the table entry its children in the tree Could compute two very large tables Ops x Possible Rows Ops x Possible Rows Replace the entire inner loop(s) with table lookup and an assignment Building the tables is slow, but the resulting matcher is extremely fast Tile(n) / n is a node in an AST / if nisaleafnodethen Match(n, ).rule { lowcost rule that matches n,ineachclass} Match(n, ).cost { corresponding cost } else if nisaunarynodethen Tile(child(n)) Match(n,).rule invalid Match(n,).cost largest integer for each rule r where operator(r) = operator(n) if (child(r), child(n)) are compatible then NewCost RuleCost(r) Match(child(n),class(child(r))).cost if (Match(n,class(r)).cost > NewCost) then Match(n,class(r)).rule r Match(n,class(r)).cost NewCost else if nisabinarynodethen Tile(left(n)) Tile(right(n)) FIGURE 11.9 Match(n,).rule invalid Match(n,).cost largest integer for each rule r where operator(r) = operator(n) if (left(r), left(n)) and (right(r), right(n)) are compatible then NewCost RuleCost(r) Match(left(n), class(left(r))).cost Match(right(n), class(right(r))).cost if (Match(n,class(r)).cost > NewCost) then Match(n,class(r)).rule r Match(n,class(r)).cost NewCost Compute LowCost Matches to Tile an AST COMP, Fall Would like to shrink the tables; see [Chase, POPL 1987].

46 What Happens Next? The algorithm now computes a set of lowcost tilings The instruction selector needs to emit the assembly code, driven by the matches and their code templates At each node, it has the low cost rule for each class Two step process: mark the choices & emit the code Pass 1: Walk the tree, top to bottom, and mark choice of rules Choice of one tile often determines the choices at its subtrees Pass : Walk the tree, bottom to top, and emit code Tie together tiles with temporary register names (e.g., r new ) COMP, Fall 017 5

47 Instruction Selection via TreePattern Matching Rule Choices Only rules that produce code are shown 3 1 a: at b: at (call by ref) v: at COMP, Fall Stmt T1 T T3 Reg , , , , 6, 7 1 1, 15 11, 3, 53

48 Instruction Selection via TreePattern Matching Final Code for the Example Node Rule Emitted Code 6 subi r arp, r a 7 5 load r a r b 8 5 load r b r c r d loadai r d, r e 13 7 loadai r e, r f 1 multi r f, r g 1 a: at b: at (call by ref) v: at sub r c, r g r h storeai r h r arp, COMP, Fall 017 5