We discovered some slightly unintuitive (to us) behavior with regard to a dynamic-extent array with an :initial-element specified.   Consider:

(defun make-it (n initial)
  (declare ((integer 0 4094) n)) ; less than a page (though safety 0 doesn't care)
  (declare (optimize (speed 3) (safety 0)))
  (let ((foo (make-array n :initial-element initial)))
    (declare (dynamic-extent foo))
    (use-it foo)))

(defun make-it-2 (n initial)
  (declare ((integer 0 4094) n))
  (declare (optimize (speed 3) (safety 0)))
  (let ((foo (locally (declare (optimize (speed 1))) ; make it NOT more important than space
         (make-array n :initial-element initial))))
    (declare (dynamic-extent foo))
    (use-it foo)))

The latter is, on a net basis considering GC time, faster because of a *decreased* speed quality.
This is because the top MAKE-IT function can't dx-allocate the array.
It can't dx-allocate because the compiler wants to inline the code for FILL and winds up doing something too hairy (allegedly) to be good-for-dx.  It's in this transform:

(deftransform fill ((seq item &key (start 0) (end nil))
                    (vector t &key (:start t) (:end t))
                    *
                    :node node)

in the '(policy node (> speed space))' case where it unrolls the FILL.
By *not* having that transform be done, you *can* call the ordinary FILL, so that the result of ALLOCATE-VECTOR becomes good-for-dx.

This is unfortunate. One of our hackers has a patch pending to QPX which separates every use of a dx make-array from a 'fill' which occurs later in a form's body. If we're going to do something like that I'd rather see the make-array wrapped in (with-really-dxable-policy) although the best fix of all would be for the compiler not to be so naive; I am at a loss for how to fix that cleanly.

Thoughts ?