>>>>> "rif" == rif <[EMAIL PROTECTED]> writes:
rif> In this case, it seems like your out-of-registers explanation is
rif> correct. l2-distance-squared is an inlined function that seems like
rif> it'd use quite a few floating point registers. Furthermore, if I
I made up an l2-distance-squared function of my own, since you never
sent one. I still only see a couple for FP registers.
rif> uninline l2-distance-squared, this particular compiler note goes away.
rif> (The whole program gets much slower, because I get an extra function
rif> call and a floater-to-point conversion for EVERY iteration, but at
rif> least that particular warning goes away.).
In this case, you might want to investigate block compilation. You
won't have to inline l2-d-s, but I think it allows the compiler to
arrange it so that args and results don't have to be boxed. But check
the User's manual to be sure.
rif> Note that in AllegroCL the situation is somewhat different, in that
rif> it's crucially important to declare that your arrays are 1D:
rif> (declare (type (simple-array fixnum *) foo))
This says FOO is a simple-array of fixnums, but any number of
dimensions. Did you really mean (simple-array fixnum (*)) which means
FOO is a 1-D array of fixnums?
rif> rather than
rif> (declare (type (simple-array fixnum) foo))
rif> but in CMUCL I don't believe this makes any difference.
I think these mean the same. But I get notes about having to do
runtime array-dimension. If you specify the number of dimensions, you
won't get these notes. Something like (simple-array fixnum (* *))
says the array has 2 dimensions, each of which is unknown.
Ray
