On 12-Dec-08, at 4:13 PM, Jud Leonard wrote:
> Compiling the attached short program reports "deleting unreachable
> code" for the dpb 7 form, when compiled by SBCL 1.0 on my Athlon
> running SUSE 10.3, and by SBCL 1.0.23 on my Mac G5 (PPC) running
> MacOSX 10.4, but does not complain and apparently runs correctly
> when compiled by SBCL 1.0.23 on my MacBook Pro (Intel) running
> MacOSX 10.5.
Attached function:
> (defun hs-set1 (str ind val)
> (multiple-value-bind (quo rem) (floor ind (floor (integer-length
> most-positive-fixnum) 3))
> (cond ((< -1 val 7) (setf (aref str quo)
> (dpb val (byte 3 (* 3 rem))
> (aref str quo))))
> ((null val) (setf (aref str quo)
> (dpb 7 (byte 3 (* 3 rem))
> (aref str quo))))
> (t (break "hs-set value out of range ~d" val)))))
The unreachable code note isn't for the dpb form, but for the complete
(setf aref) form (where it will actually be reported depends on
previous optimisation passes). If the (< -1 val 7) form executed
correctly [by returning T or NIL, but without erroring out], then val
is a number, and numbers cannot be NULL. Thus, (null val) is always
false [when it actually executes], and the consequent form is
deleted. Code deletion notes are just that, notes; although they
often denote a logic problem, they do not guarantee the existence of a
problem (while warnings or style warnings usually do). The fact that
the code runs correctly on your obviously limited test cases isn't a
symptom of anything.
> The program of which this function is a part seems to work better on
> the MacBook, but I haven't yet determined whether this is the cause.
If this function is supposed to execute efficiently, you should
declare the types of str, ind and val. You're wasting an enormous
amount of time in safety checks and generic arithmetic. Trying to
ascertain any cause for a difference in execution speed on the current
code is an exercise in futility.
> In any case, if I replace the form (floor (integer-length most-
> positive-fixnum) 3) with 9 (the calculated value on the MacBook), it
> seems happy. If I replace it with 20 (the value on the Athlon), the
> Athlon complains, the MacBook is content.
What do you mean by "happy", "complains" and "content"? Neither of
your changes will affect the fact that (null val) will always be false
whenever it executes.
Paul Khuong
|