From: John K. <jk2...@ya...> - 2003-11-04 21:25:31
|
Hello, When I compile the appended code I see an unexpected float boxing NOTE, as follows: ; (THE DOUBLE-FLOAT R) ; ; note: doing float to pointer coercion (cost 13) from r to "<return value>" ; compilation unit finished ; caught 2 STYLE-WARNING conditions ; printed 1 note I've marked the location in the code as "BOXING HERE" I think there is no reason for float boxing to occur here because r-max is a double, and r inside the loop is a double, and optimization is set to SPEED. Strangely, the compiler doesn't say that the final return value r-max is boxed, however. Is it a misplaced boxing message, or is r boxed and the location then used for the final return value? When I change the final returned value from r-max to the boolean (> r-max 1000d0) the boxing message for r goes away. (lisp-implementation-version) => "0.8.4" (lisp-implementation-type) => "SBCL" system: debian linux Is this a bug, or a known quirk of the compiler? Apologies if this has been asked before. I searched my records of the list and didn't find this. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defun I-of-rho (r-proj &key (r-max nil)) "stripped down test function to demonstrate boxing glitch" (declare (type (double-float 0d0) r-proj) (type (or null double-float) r-max) (optimize speed)) (let* ((r-max (or r-max ;; compute r at which density has fallen (loop for r of-type double-float = r-proj then (* 2d0 r) until (> r (* 100d0 r-proj)) ;; BOXING HERE finally (return (the double-float r))))) ) ;; (rk nil)) (declare (type (double-float 0d0) r-max)) ;; ;; r-max)) ;; return r-max to ensure it is always used __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree |
From: Rob M. <ra...@ri...> - 2003-11-05 15:49:01
|
Since SBCL doesn't support block compilation, any DEFUN that returns a float will *always* cons a float. Where the coercion is attributed may vary somewhat. If you avoid returning a float by returning a boolean instead, then the consing goes away. If you inline expand the function, then the consing can be avoided at the call site, but you will still get a consing note at the out-of-line definition. If the function is only used locally, you can get the effect of block compilation by making the function a local lexical function using FLET or LABELS. In this case, return value boxing can also be avoided. Rob |
From: John K. <jk2...@ya...> - 2003-11-05 21:21:18
|
--- Rob MacLachlan <ra...@ri...> wrote: > > Since SBCL doesn't support block compilation, any DEFUN that returns a > float will *always* cons a float. Where the coercion is attributed may > vary somewhat. If you avoid returning a float by returning a boolean > instead, then the consing goes away. > Thanks for the reply; this bit I understand, however. What I didn't get was why the float consing was reported in the wrong place. I was confused that 'r' was reported as consed when 'r' was an internal double-float variable that was not returned, and I spent a long time tweaking the code trying to get this message to vanish. So my question was whether the misleasing boxing NOTE is a bug, or a just a known shortcoming of the compiler. __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree |