optimization: constraint propagation should be optional

[Nikodemus Siivola]

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.

[Nikodemus Siivola (nikodemus)]

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.

[Stas Boukarev (stassats)]

Doesn't seem to be much of a problem these days, and disabling constraint propagation leads to all kinds of bad things.