PPC FAST-ASH-LEFT/FIXNUM/=>FIXNUM

[Nikodemus Siivola]

Compiling

    (lambda (b)
      (declare (type (integer -2 14) b))
      (declare (ignorable b))
      (ash (imagpart b) 57))

on PPC (and possibly on other platforms, but not on x86 at least) gives an error
during the emission of FAST-ASH-LEFT/FIXNUM=>FIXNUM as the assembler
attempts to stuff a too-large constant into the immediate field of a PPC instruction.
Either the VOP should be fixed or the compiler should be taught how to transform
this case away, paying particular attention to side-effects that might occur in the
arguments to ASH.

Confirmed for 1.0.22.

[Alastair Bridgewater (alastair-bridgewater)]

A simpler test case: (defun foo (bar) (declare (type (integer 0 0) bar)) (ash bar 57))

Essentially, this only happens when the compiler knows that the value to shift is zero, thus can be shifted by any number of bits and it still remain a fixnum, thus triggering the fast-ash-left/fixnum=>fixnum vop.

At the same time, since you can't produce any value other than zero by shifting a zero, why isn't this constant-folded out in the first place?

This does not fail for the variable-count case because a zero is still a zero even after being shifted by the "wrong" amount.

One fix for this bug would be to implement a fast-ash-left-c/fixnum=>fixnum vop for ppc. I would expect this bug to occur on any target for which said vop is not implemented. This would mean that sparc, mips, alpha, and hppa may be vulnerable.

[Paul Khuong (pvk)]

I think this is an instance of 1.0.30.2 (Allow constant-folding on values of an EQL type), the case that wasn't handled by the patch. While the type is obviously a constant value, the LVAR isn't CONSTANT-LVAR-P (yet). CONSTANT-LVAR-P could be extended to handle character set types and numeric types.