Next: Style Recommendations, Previous: Multiple Values Optimization, Up: Source Optimization [Contents][Index]
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:
(defun my-zerop () (zerop x))
gives this warning:
In: DEFUN MY-ZEROP (ZEROP X) ==> (= X 0) Warning: Undefined variable: 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:
(defun foo (x) (logand 1 x))
gives this efficiency note:
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.
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.
You will also notice source-to-source optimizations when efficiency
notes are enabled (see efficiency-notes.) 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.
Next: Style Recommendations, Previous: Multiple Values Optimization, Up: Source Optimization [Contents][Index]