3.6 Compiler Policy Control

       

The compilation policy specified by optimize declarations affects the behavior seen in the debugger. The debug quality directly affects the debugger by controlling the amount of debugger information dumped. Other optimization qualities have indirect but observable effects due to changes in the way compilation is done.

Unlike the other optimization qualities (which are compared in relative value to evaluate tradeoffs), the debug optimization quality is directly translated to a level of debug information. This absolute interpretation allows the user to count on a particular amount of debug information being available even when the values of the other qualities are changed during compilation. These are the levels of debug information that correspond to the values of the debug quality:

0

Only the function name and enough information to allow the stack to be parsed.

> 0

Any level greater than 0 gives level 0 plus all argument variables. Values will only be accessible if the argument variable is never set and speed is not 3. CMU Common Lisp allows any real value for optimization qualities. It may be useful to specify 0.5 to get backtrace argument display without argument documentation.

1

Level 1 provides argument documentation (printed arglists) and derived argument/result type information. This makes  describe more informative, and allows the compiler to do compile-time argument count and type checking for any calls compiled at run-time.

2

Level 1 plus all interned local variables, source location information, and lifetime information that tells the debugger when arguments are available (even when speed is 3 or the argument is set.) This is the default.

3

Level 2 plus all uninterned variables. In addition, lifetime analysis is disabled (even when speed is 3), ensuring that all variable values are available at any known location within the scope of the binding. This has a speed penalty in addition to the obvious space penalty.

As you can see, if the speed quality is 3, debugger performance is degraded. This effect comes from the elimination of argument variable special-casing (see section 3.4.1.) Some degree of speed/debuggability tradeoff is unavoidable, but the effect is not too drastic when debug is at least 2.

    In addition to inline and notinline declarations, the relative values of the speed and space qualities also change whether functions are inline expanded (see section 5.8.) If a function is inline expanded, then there will be no frame to represent the call, and the arguments will be treated like any other local variable. Functions may also be ``semi-inline'', in which case there is a frame to represent the call, but the call is to an optimized local version of the function, not to the original function.