The code compiled to bytecodes with optimization levels

(OR (>= 0 SPACE) (<= 1 SPEED))

(by COMPILE, COMPILE-FILE, or (COMPILE)) will be just-in-time (i.e., on the first execution) compiled to native code using GNU lightning.

Compiler macros are expanded in the compiled code only, and ignored by the interpreter.

When a DEFUN form is EVALuated, the macros used there are expanded, so they must be already defined, and their (re)definition does not affect functions which are already defined.

This means that even the interpreted code is minimally compiled in CLISP.

Non-conforming code that does not follow the rule

can produce quite unexpected results, e.g., observable differences between compiled and interpreted programs:

(defun adder-c (value) (declare (COMPILE)) (lambda (x) (+ x value)))
⇒ ADDER-C	; compiled function; value is lexical
(defun adder-i (value) (lambda (x) (+ x value)))
⇒ ADDER-I	; interpreted function; value is lexical
(defparameter add-c-10 (adder-c 10))
⇒ ADD-C-10	; compiled function
(defparameter add-i-10 (adder-i 10))
⇒ ADD-I-10	; interpreted function
(funcall add-c-10 32)
⇒ 42	; as expected
(funcall add-i-10 32)
⇒ 42	; as expected
(defvar value 12)
⇒ VALUE	; affects ADDER-I and ADD-I-10 but not ADDER-C and ADD-C-10
(funcall add-c-10 32)
⇒ 42	; as before
(funcall add-i-10 32)
⇒ 44	; value is now dynamic!

Non-conformance. The code shown above has a SPECIAL proclamation (by DEFVAR) for the variable value in the execution environment (before the last two FUNCALLs) but not in the compilation environment: at the moment the ADDER-I function is defined, value is not known to be a SPECIAL variable. Therefore the code is not conforming.