Re: [Sbcl-devel] cross-complilation considered harmful - help!

[Stas B. <sta...@gm...>]

Douglas Katzman <do...@go...> writes:

> How would one go about tracking down why the xc is producing such different
> code than results from pasting in the exact same DEFUN to the warm image?
>
>  * (disassemble 'compute-unpackified-info-size)
>
> ; disassembly for COMPUTE-UNPACKIFIED-INFO-SIZE
>
> ; Size: 426 bytes. Origin: #x100181A3B6
>
> ...
>
>
> * (defun compute-unpackified-info-size (vector) ...)
>
> ; disassembly for COMPUTE-UNPACKIFIED-INFO-SIZE
>
> ; Size: 263 bytes. Origin: #x1003874261
>
> ...
>
> This means I've not used 'def!type' when I should have, and the like, I
> assume?
No, this means:
a) The original compute-unpackified-info-size is compiled with speed = 3
b) vector-info is loaded before numbers.lisp, where the inline
definition of %floor is defined.
c) floor derive-type optimizer is conditionalized out from sb-xc-host
due to CROSS-FLOAT-INFINITY-KLUDGE

So:
(in-package :sb-c)

(declaim (notinline %floor) (optimize speed))
(defoptimizer (floor derive-type) ((a b)))
(setf sb-regalloc:*register-allocation-method* :greedy)

(defun compute-unpackified-info-size-2 (vector)
  (declare (simple-vector vector)
           (optimize speed))
  (do-packed-info-vector-aux-key (vector) ()
    ;; off-by-one: the first info group's auxilliary key is imaginary
    (1- (truly-the fixnum (ash total-n-fields 1)))))

will produce exactly the same code.


-- 
With best regards, Stas.