Enhancement: elimination of shifts before certain comparisons

Bug #1850920 reported by Paul F. Dietz
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
New
Undecided
Unassigned

Bug Description

(Wishlist optimizations)

(zerop (ash x y)) should simplify to (zerop x) when y is known to be nonnegative. However, an unnecessary shift is being left in the generated code.

(defun f5 (x)
  (declare (type (integer 0 1000000) x))
  (zerop (ash x 1)))

* (disassemble 'f5)
; disassembly for F5
; Size: 27 bytes. Origin: #x52D2D9F6 ; F5
; 9F6: 48D1E2 SHL RDX, 1
; 9F9: 4885D2 TEST RDX, RDX
; 9FC: BA17001050 MOV EDX, #x50100017 ; NIL
; A01: 41BB4F001050 MOV R11D, #x5010004F ; T
; A07: 490F44D3 CMOVEQ RDX, R11
; A0B: 488BE5 MOV RSP, RBP
; A0E: F8 CLC
; A0F: 5D POP RBP
; A10: C3 RET

Similarly, (eql c1 c2) and (= (char-code c1) (char-code c2)) should generate the same code (with c1 and c2 being declared to be characters), but the latter has unnecessary shifts.

More elaborately, the comparison could appear after more complicated integer logical operations, like logior and logxor. If these operations do not change the low order bits introduced by the shifts then the shifts can be optimized away. The place this comes up is in implementing a sequence of character comparisons by logior of logxor of the char-codes, then testing for equality to zero.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.