| Reorder the tree code while maintaining program semantics | ||
| Why? | ||
| enable easier code generation | ||
| more efficient code also | ||
| Dealing with side-effecting expressions | ||
| Determining Basic Blocks | ||
| Determining Traces | ||
Mismatches between Tree code and m/c architectures
| Tree code is simple (!) to generate from the abstract syntax of a language | ||
| Mismatches however | ||
| ESEQ fixes order of evaluation of subtrees | ||
| CALL does the same | ||
| CALL nodes within argument list of other CALL nodes complicates register allocation | ||
| CJUMP has two possible targets | ||
| Use these as a vehicle to look at tree rewriting | ||
| Defined as trees with | |||
| No SEQ or ESEQ nodes | |||
| A CALL node can only be found directly in | |||
| An EXP(…) – in which case it’s a void call | |||
| A MOVE( TEMP t, … ) – result is stored at once | |||
| Rewriting rules for lifting SEQ/ESEQ… | |||
| Rewriting rules for lifting CALLs… | |||
| Removing the SEQs | |||
| A control-flow analysis | |
| Only jumps and jump targets are of intererest |
| Basic blocks can be now rearranged into any ordering | ||
| All start with a label, end with a jump | ||
| Trace | ||
| Sequence of statements that could be executed consecutively | ||
| Find a set of non-overlapping traces that covers the entire program | ||
| Can remove unconditional jumps directly followed by targets | ||
| Most false targets now follow conditional jumps | ||
| I’ll set up the code for download after next Tuesday’s tutorial session | ||
| Read through Chapter 8 | ||
| In conjunction with your notes, aim to pick up the general techniques that are being used | ||