Design of CMU Common Lisp.pdf - Common Lisp.net

Chapter 9
Type checking
We need to do a pretty good job of guessing when a type check will ultimately need to be done. Generic
arithmetic, for example: In the absence of declarations, we will use the safe variant, but if we don’t know this,
we will generate a check for NUMBER anyway. We need to look at the fast-safe templates and guess if any of
them could apply.
We compute a function type from the VOP arguments and assertions on those arguments. This can be
used with Valid-Function-Use to see which templates do or might apply to a particular call. If we guess that
a safe implementation will be used, then we mark the continuation so as to force a safe implementation to be
chosen. [This will happen if ICR optimize doesn’t run to completion, so the ICR optimization after type check
generation can discover new type information. Since we won’t redo type check at that point, there could be a
call that has applicable unsafe templates, but isn’t type checkable.]
[### A better and more general optimization of structure type checks: in type check conversion, we look
at the *original derived* type of the continuation: if the difference between the proven type and the asserted
type is a simple type check, then check for the negation of the difference. e.g. if we want a FOO and we know
we’ve got (OR FOO NULL), then test for (NOT NULL). This is a very important optimization for linked lists of
structures, but can also apply in other situations.]
If after ICR phases, we have a continuation with check-type set in a context where it seems likely a check will
be emitted, and the type is too hairy to be easily checked (i.e. no CHECK-xxx VOP), then we do a transformation
on the ICR equivalent to:
(... (the hair ) ...)
==>
(... (funcall \#’(lambda (\#:val)
(if (typep \#:val ’hair)
\#:val
(%type-check-error \#:val ’hair)))
)
...)
This way, we guarantee that VMR conversion never has to emit type checks for hairy types.
[Actually, we need to do a MV-bind and several type checks when there is a MV continuation. And some
values types are just too hairy to check. We really can’t check any assertion for a non-fixed number of values,
since there isn’t any efficient way to bind arbitrary numbers of values. (could be done with MV-call of a morearg
function, I guess...) ]
[Perhaps only use CHECK-xxx VOPs for types equivalent to a ptype? Exceptions for CONS and SYMBOL?
Anyway, no point in going to trouble to implement and emit rarely used CHECK-xxx vops.]
One potential lose in converting a type check to explicit conditionals rather than to a CHECK-xxx VOP is
that VMR code motion optimizations won’t be able to do anything. This shouldn’t be much of an issue, though,
since type constraint propagation has already done global optimization of type checks.
This phase is optional, but should be done if anything is more important than compile speed.
Type check is responsible for reconciling the continuation asserted and derived types, emitting type checks
if appropriate. If the derived type is a subtype of the asserted type, then we don’t need to do anything.
28