SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

It has long been proposed to add a peephole optimizer (POP) to the compiler. Many wise programmers have started down this road (scan through #lisp and comp.lang.lisp), and have given up. I took a look at it also, and before I run away screaming, I wanted to post some notes in case some champion is inspired to accept the challenge.

[Feel free to correct any wrong info in the following]

Consensus seems to be that the Python compiler is very good about avoiding much of the need for a peephole optimizer. However there are still some optimizations and flow analysis that can be done to the assembly code, and that would be a win.

The problem is that there is no place where the assembly code is collected in one place. Instead, the emitter calls each VOP in turn, and the VOP then directly emits machine code into a code vector. There is minimal cleanup to the machine code (using Backpatches and Choosers), but these are basically a kludge for a few things that must be fixed later (after the branch labels are calculated?).

Before the fun of actually implementing a peephole optimizer (POP), there is the major issue of how to shoehorn it into the compiler. There seems to be four possible options:

1. Buffer up the assembly language: rewrite the emitter to collect the assembly instructions in a buffer (make one big VOP) POP them and then emit machine code

• +the Right Way to do it
• +adds a stage to the compiler to allow code flow analysis and easily implement a whole range of code optimizations, a big win in the long run
• +avoid or limit backpatches and choosers
• +works across most of the platforms
• -sounds straightforward, but the instruction emitter code is very scary
• -major rewrite of the assembler, and probably affect many of the VOPs
• -slow down compilation more, even if POP stage is skipped

2. Capture the assembly instructions as the emitter emits the machine code, then POP the assembler and make appropriate changes to the machine code.

• +easier to implement?
• +wont slow down compiler if not activated

• -clunkiness of modifying assembly code and machine code at the same time
• -have to have special-case code for different CPU machine instructions?

3. Do some VOP boundary analysis as the emitter is running. This would probably catch the familiar

mov esp ebx
mov ebx esp

code we all know and love.

• +probably quick to implement, using Choosers perhaps?
• -basically a kludge
• -not extendable, could only catch some specific boundary cases

4. Separate post-compiler POP stage, use disassembler to recreate assembly code, and then process is similar to #2.

• +optional separate optimizer
• +doesn't mess with the compiler
• -probably platform specific
• -have to deal with branch labels at this stage
• -require lots of coding

This page is linked from: index  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively