optimization: constraint propagation should be optional
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Won't Fix
|
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 |
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.