wanted: compiler smartness involving MOD, and +
Bug #663979 reported by
Tobias C. Rittweiler
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| SBCL |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
I don't know what's the obstacle exactly (lack of return smartness of MOD,
or of CFG and assignment analysis), but it would be *nice* if the following
two functions would compile down to fixnum arithmetics.
(defun foo1 ()
(declare (optimize speed))
(let ((count 0))
(dotimes (i 100)
(when (zerop (setq count (mod (1+ count) 10)))
(bar)))))
(defun foo2 ()
(declare (optimize speed))
(loop repeat 100
for count = 0 then (mod (1+ count) 10)
when (zerop count) do (bar)))
Revision history for this message
| Kalyanov Dmitry (kalyanov-dmitry) wrote | #1 |
Revision history for this message
| Kalyanov Dmitry (kalyanov-dmitry) wrote | #2 |
| Changed in sbcl: | |
| importance: | Undecided → Wishlist |
| status: | New → Triaged |
| tags: | added: optimization |
To post a comment you must log in.
I've read that CMUCL and SBCL have trouble with type inference when assignment is involved.
Just declaring count to be of integer type removes compiler notes about optimization and uses fixnum arithmetics.
(defun foo1 ()
(declare (optimize speed))
(let ((count 0))
(declare (type integer count))
(dotimes (i 100)
(when (zerop (setq count (mod (1+ count) 10)))
(bar)))))
(defun foo2 ()
(declare (optimize speed))
(loop repeat 100
for count of-type integer = 0 then (mod (1+ count) 10)
when (zerop count) do (bar)))