As of version 0.6.4, SBCL still uses most of the CMU CL code for compiler policy. The CMU CL code has many features and high-quality documentation, but the two unfortunately do not match. So this area of the compiler and its interface needs to be cleaned up. Meanwhile, here is some rudimentary documentation on the current behavior of the system.
Compiler policy is controlled by the optimize declaration. The compiler supports the ANSI optimization qualities, and also an extension sb-ext:inhibit-warnings.
Ordinarily, when the speed quality is high, the compiler emits notes to notify the programmer about its inability to apply various optimizations. Setting sb-ext:inhibit-warnings to a value at least as large as the speed quality inhibits this notification. This can be useful to suppress notes about code which is known to be unavoidably inefficient. (For example, the compiler issues notes about having to use generic arithmetic instead of fixnum arithmetic, which is not helpful for code which by design supports arbitrary-sized integers instead of being limited to fixnums.)
Note: The basic functionality of the optimize inhibit-warnings extension will probably be supported in all future versions of the system, but it will probably be renamed when the compiler and its interface are cleaned up. The current name is misleading, because it mostly inhibits optimization notes, not warnings. And making it an optimization quality is misleading, because it shouldn't affect the resulting code at all. It may become a declaration identifier with a name like sb-ext:inhibit-notes, so that what's currently written
(declaim (optimize (sb-ext:inhibit-warnings 2)))would become something like(declaim (sb-ext:inhibit-notes 2))
(In early versions of SBCL, a speed value of zero was used to enable byte compilation, but since version 0.7.0, SBCL only supports native compilation.)
When safety is zero, almost all runtime checking of types, array bounds, and so forth is suppressed.
When safety is less than speed, any and all type checks may be suppressed. At some point in the past, CMU CL had a more nuanced interpretation of this. However, SBCL doesn't support that interpretation, and setting safety less than speed may have roughly the same effect as setting safety to zero.
The value of space mostly influences the compiler's decision whether to inline operations, which tend to increase the size of programs. Use the value 0 with caution, since it can cause the compiler to inline operations so indiscriminately that the net effect is to slow the program by causing cache misses or swapping.