The compiler implements a number of operation-specific optimizations as source-to-source transformations. You will often see unfamiliar code in error messages, for example:
gives this warning:(defun my-zerop () (zerop x))
The original zerop has been transformed into a call to =. This transformation is indicated with the same ==> used to mark macro and function inline expansion. Although it can be confusing, display of the transformed source is important, since warnings are given with respect to the transformed source. This a more obscure example:In: DEFUN MY-ZEROP (ZEROP X) ==> (= X 0) Warning: Undefined variable: X
gives this efficiency note:(defun foo (x) (logand 1 x))
Here, the compiler commuted the call to logand, introducing temporaries. The note complains that the first argument is not a fixnum, when in the original call, it was the second argument. To make things more confusing, the compiler introduced temporaries called c::x and c::y that are bound to y and 1, respectively.In: DEFUN FOO (LOGAND 1 X) ==> (LOGAND C::Y C::X) Note: Forced to do static-function Two-arg-and (cost 53). Unable to do inline fixnum arithmetic (cost 1) because: The first argument is a INTEGER, not a FIXNUM. etc.
You will also notice source-to-source optimizations when efficiency notes are enabled (see section 5.13.) When the compiler is unable to do a transformation that might be possible if there was more information, then an efficiency note is printed. For example, my-zerop above will also give this efficiency note:
In: DEFUN FOO (ZEROP X) ==> (= X 0) Note: Unable to optimize because: Operands might not be the same type, so can't open code.