On Mon, May 18, 2009 at 11:23 AM, Vitaly Mayatskikh
> I found high cost generators for VOP FAST-+/(UN)SIGNED=>(UN)SIGNED
> prevent compiler to make better code. Instead of using these VOPs, it
> uses MOVE-WORD and FAST-+/FIXNUM. That's not fair, `lea' and `add'
> instructions cost the same price for CPU when using them for untagged
> Other patch is a new VOP: FAST-+/FIXNUM-SIGNED=>FIXNUM. It's possible
> to utilize CPU instruction LEA for fast addition of fixnum and
> untagged value.
These are a nice idea; did you check that they're not slowing down the
(+ <fixnum> <fixnum>) case? Because the lower cost is going to
indicate to the compiler that those VOPs are better for fixnum/fixnum
addition, which is going to pessimize a lot of code unnecessarily.
You can already see the compiler doing this in your original examples,
where it chose untagged arithmetic for the loop index. I'm guessing
this is the sort of slowdown Martin is seeing downthread.
Testing something like:
(defun foo (x y)
(declare (type (unsigned-byte 16) x y))
(+ x y))
and variants thereof (different types for x and y) along with any
other mostly-integer, mostly-fixnum code that you can lay your hands
on with one or both of these patches would be a good idea.
Recompiling SBCL itself with these patches and checking a few
functions (sequence, bignum, and bit-bashing functions are my guesses)
to ensure the compiler isn't doing silly things would be good, too.