optimization: constraint propagation should be optional

Bug #313226 reported by Nikodemus Siivola on 2009-01-02
2
Affects Status Importance Assigned to Milestone
SBCL
Medium
Unassigned

Bug Description

Constraint propagation is often one of the larger timesinks in compilation. Turning it off for COMPILATION-SPEED > SPEED would be good -- and it seems that it was originally intended as an optional pass.

However, changes in the compiler since days of yore have made constraint propagation effectively non-optional, causing bogus WARNINGs or worse if it is omitted.

Example:

  (lambda (x)
    (declare (type (or simple-vector list) x))
    (svref (coerce x 'simple-vector) 0))

  (coerce x 'simple-vector)

becomes

  (if (simple-vector-p x)
      x
      (replace (make-array (length x)) x))

which in turn causes compilation of SVREF to complain from a possible type-mismatch
(wanted SIMPLE-VECTOR, has (OR SIMPLE-VECTOR LIST)) for the first leg of the
IF. Adjusting the transform to plug in a TRULY-THE would take care of this,
but *any* transform like this is liable to cause such bogus warnings.

Changed in sbcl:
importance: Undecided → Medium
status: New → Confirmed
Nikodemus Siivola (nikodemus) wrote :

The attached patch doesn't quite get rid of constraint propagation, but reduces it.

(setf sb-c::*constraint-propagation-rounds* 0)

makes things build a fair bit faster (50% reduction in compile-time eg. for DEFINE-EXTERNAL-FORMAT :UTF-8) -- but breaks some things.

(setf sb-c::*constraint-propagation-rounds* 1)

should always work, but improves compiler performance by only about 6% on average: for some cases likely by much more. No measurements on the effect of compiled code yet.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers