Opened 7 years ago

Closed 7 years ago

#20 closed defect (fixed)

Modular arith bug?

Reported by: rtoy Owned by: somebody
Priority: major Milestone:
Component: Core Version: 19e
Keywords: Cc:

Description (last modified by rtoy)

(declaim (inline mat3neg mat3neg-a))
(defun mat3neg (tt v)
  (ldb (byte 32 0) (ash v (- tt))))

(defun mat3neg-a (tt v)
  (logand #xffffffff (ash v (- tt))))

(defun zot (z2)
  (declare (type (unsigned-byte 32) z2)
	   (optimize speed (safety 0)))
  (mat3neg -28 z2))

(defun zot-a (z2)
  (declare (type (unsigned-byte 32) z2)
	   (optimize speed (safety 0)))
  (mat3neg-a -28 z2))

Compile zot and there are lots of compiler notes, from mat3neg. But compile zot-a and there's just one for boxing up the result.

However, zot and zot-a are functionally identical, so zot and zot-a should produce the same code. But zot has to do a full call to ash and two-arg-and.

The ldb must be confusing the compiler somehow.

Change History (3)

comment:1 Changed 7 years ago by rtoy

  • Description modified (diff)

comment:2 Changed 7 years ago by rtoy

The issue is partly caused by ldb and, perhaps, partly by ash modular function optimizer.

(ldb (byte size posn) x) is source-transformed to (%ldb size posn x), which has a deftransform that converts it to (logand (ash x (- posn)) (ash (1- (ash 1 vm:word-bits)) (- size vm:word-bits)).

This expression must confuse logand-defopt-helper. One workaround is to change the %ldb to produce simpler expressions when posn and size are known constants.

comment:3 Changed 7 years ago by rtoy

  • Resolution set to fixed
  • Status changed from new to closed

This particular issue is fixed and should work as expected in the 2008-09 snapshot. The workaround was to change %ldb to optimize the expression at compile-time as much as possible.

Closing this particular issue.

Note: See TracTickets for help on using tickets.