Steel Bank Common Lisp

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

Reported by Nikodemus Siivola on 2008-12-17
2
Affects Status Importance Assigned to Milestone
SBCL
Medium
Paul Khuong

Bug Description

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.

description: updated
description: updated
description: updated
Changed in sbcl:
importance: Undecided → Medium
status: New → Confirmed

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) wrote :

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.

Paul Khuong (pvk) on 2010-10-10
Changed in sbcl:
assignee: nobody → Paul Khuong (pvk)
status: Confirmed → In Progress
Paul Khuong (pvk) on 2010-10-12
Changed in sbcl:
status: In Progress → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers