OK. Thanks to all who've helped me to think about this. I now
understand what is happening. I'm still struggling with why, but I'm
guessing that the nut is cracked and you can explain it to me. A very
simple example that demonstrates the phenomena (I no longer call it a
problem or bug) is:
(declaim (optimize (speed 3) (debug 0) (safety 0)))
(defun copy-frame (frame n)
(declare (type (simple-array double-float) frame))
(declare (type fixnum n))
(let ((new-frame (make-array n :element-type 'double-float)))
(dotimes (i n)
(declare (type fixnum i))
(setf (aref new-frame i) (aref frame i)))
new-frame))
(defvar frame (make-array 10 :element-type 'double-float))
The first time through, the defun of copy-frame has not yet seen the
defvar of frame, and compiles without notes. If I recompile, I get
In: DEFUN COPY-FRAME
(AREF FRAME I)
--> LET*
==>
(KERNEL:DATA-VECTOR-REF ARRAY KERNEL:INDEX)
Note: Unable to optimize due to type uncertainty:
The first argument is a VECTOR, not a SIMPLE-ARRAY.
Note: Forced to do full call.
Unable to do inline array access (cost 7) because:
The first argument is a VECTOR, not a (SIMPLE-ARRAY DOUBLE-FLOAT (*)).
I don't know why this is happening, I would have thought that the fact
that frame is a parameter to copy-frame meant that the type
declaration in copy-frame applied to what was passed in, not to the
def var'd frame, and it also seems to me that the the defvar gives a
frame which does match the type declaration. So generally, I'm still
not clear why this is happening, but it seems I can fix it by not
having a defvar in my package that matches the parameter names of
functions. Any explanations?
Cheers,
rif
