Christophe Rhodes writes:
> Really this distinction is between
> tagged and untagged, preferring the untagged case, but Nathan's
> canonical test case
> (defun foom (x y)
> (declare (fixnum x y))
> (logand (logxor x y) most-positive-fixnum))
> now compiles to
> ; 0A6D5AAE: 8BD0 MOV EDX, EAX
> ; B0: 31FA XOR EDX, EDI
> ; B2: 81E2FCFFFF7F AND EDX, 2147483644
So, at least some of this goodnes is because we have fewer smod30 than
mod32 functions, and in particular logxor blocks modular
optimizations. A better test case to look at might be
(defun foom2 (x y)
(declare (fixnum x y))
(logand (logxor x (+ x y)) most-positive-fixnum))
[ which has a currently unoptimized + ]
and also
(defun foom3 (x y)
(declare (fixnum x y))
(logand (+ x (logxor x y)) most-positive-fixnum))
I attach a patch which implements the strategy for choosing modular
versions that Nathan and I discussed a while back: prefer an exact
untagged match, followed by an approximate tagged match, followed by
an approximate untagged; this should allow implementation of mod32
arithmetic on x86-64.
I have only lightly tested it, and not at all on anything that's not
an x86; in fact I'm sure it won't build anywhere else.
I'd appreciate feedback on whether this is the right path, and whether
we should be doing more work to support smod30 arithmetic.
Cheers,
Christophe