Optimisation

1. Optimisation • “Optimisation” is a misnomer – “improvement” strictly a better term • Optimisation for execution speed is most frequent, but it may be desirable to optimise other qualities of code: • space utilisation (memory footprint) – eg for embedded systems • safety of code – e.g. array bounds checks in new untested code • debuggability of code – e.g. informative backtraces giving variable names when exceptions occur • compilation speed – e.g. when regularly rebuilding code base of an entire project • power consumption – e.g. in mobile devices, switching circuits off when not needed, such as digital signal processing circuits • Optimisation is no friend of correctness – there are dangers and great care is needed http://csiweb.ucd.ie/staff/acater/comp30330.html Compiler Construction

2. Kinds of optimisation Three broad kinds of execution-speed optimisation technique used in compilers • Peephole Optimisation: Generate code in a naïve way, then set about improving it • find sequences of instructions that can be replaced with better sequences • applies mainly to optimisation for speed, maybe also for power consumption 2. Parse tree modification prior to code generation • e.g. code movement out of loops – perform complex calculations less often • e.g. tail recursion elimination – avoid some stack manipulations, calls, returns • e.g. inlining of functions and procedures – avoid overhead of calling sequences 3. Generating code carefully from the outset • e.g. maximise register utilisation in arithmetic expressions • e.g. select fast and/or multipurpose instructions when possible http://csiweb.ucd.ie/staff/acater/comp30330.html Compiler Construction

3. Optimisation tradeoffs • Optimising for one quality usually adversely impacts one or more others. E.g.s: • Safety quality – for array bounds checks, datatype checks – involves inserting more code and executing more instructions • Debug quality involves inserting code that records how memory locations correspond to program identifier symbols; and forgoing tail-recursion elimination and other parse-tree-based optimisations • Space quality may involve using calling sequences which require fewer instructions at the (many) points of call, more at the (one) entry and exit points of procedures. Compiler loses ability to make optimisations of individual calls, result is slight slowdown. • Inlining procedures to enhance speed – by avoiding call/return code sequences – involves replicating code for procedure body, taking more space http://csiweb.ucd.ie/staff/acater/comp30330.html Compiler Construction

4. Peephole optimisation A peephole selects a small subset of instructions to be examined, if the instruction sequence matches some pattern it is replaced with a better but equivalent sequence. • peephole slides over entire program, each small sequence is examined in turn • peephole is not necessarily contiguous • repeated passes worthwhile: one change often spawns more opportunities Some useful peephole optimisations deal with jumps; Others deal with basic blocks – maximal sequences of instructions with only one entry poin,t and only one exit point (which is allowed to be a conditional jump) http://csiweb.ucd.ie/staff/acater/comp30330.html Compiler Construction

5. Examples of peephole optimisations • eliminate unnecessary stores or loads • eliminate jumps to jumps • eliminate unreachable code • reduction of operator strength • replace multiply or divide by power of 2 with a shift • replace raise-to-power-2 with multiply-by-self move a, b move b, a move a, b jump LBL23 … … LBL22: jump LBL23 jump LBL22 … … LBL22: jump LBL23 jump LBL33 … code with no labels … LBL33: following code LBL33: following code http://csiweb.ucd.ie/staff/acater/comp30330.html Compiler Construction