| blob | d4a5c6c3da0286b697f05519ccf842e7be301587 |
1 ;;;; This file implements type check generation. This is a phase that
2 ;;;; runs at the very end of IR1. If a type check is too complex for
3 ;;;; the back end to directly emit in-line, then we transform the check
4 ;;;; into an explicit conditional using TYPEP.
6 ;;;; This software is part of the SBCL system. See the README file for
7 ;;;; more information.
8 ;;;;
9 ;;;; This software is derived from the CMU CL system, which was
10 ;;;; written at Carnegie Mellon University and released into the
11 ;;;; public domain. The software is in the public domain and is
12 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
13 ;;;; files for more information.
16 \f
17 ;;;; cost estimation
19 ;;; Return some sort of guess about the cost of a call to a function.
20 ;;; If the function has some templates, we return the cost of the
21 ;;; cheapest one, otherwise we return the cost of CALL-NAMED. Calling
22 ;;; this with functions that have transforms can result in relatively
23 ;;; meaningless results (exaggerated costs.)
24 ;;;
25 ;;; We special-case NULL, since it does have a source tranform and is
26 ;;; interesting to us.
38 call-cost)))
40 ;;; Return some sort of guess for the cost of doing a test against
41 ;;; TYPE. The result need not be precise as long as it isn't way out
42 ;;; in space. The units are based on the costs specified for various
43 ;;; templates in the VM definition.
57 nil))))
81 ;; FIXME: Our canonicalization isn't quite ideal for this. We get
82 ;; types such as:
83 ;;
84 ;; (OR (AND (SATISFIES FOO) (INTEGER -100 -50))
85 ;; (AND (SATISFIES FOO) (INTEGER 100 200)))
86 ;;
87 ;; here, and weakening that into
88 ;;
89 ;; (AND (SATISFIES FOO) (INTEGER -100 200))
90 ;;
91 ;; is too much work to do here ... but if we canonicalized things
92 ;; differently, we could get it for free with trivial changes here.
102 new))
108 bound
114 bound
125 rest
130 type))))
138 type)
140 ;; Simple range checks are not that expensive, and we *don't*
141 ;; want to accidentally lose eg. array bounds checks due to
142 ;; weakening, so for integer types we simply collapse all
143 ;; ranges into one.
157 samep)
158 ;; If the supertype is equal in cost to the type, we
159 ;; prefer the supertype. This produces a closer
160 ;; approximation of the right thing in the presence of
161 ;; poor cost info.
163 min-type stype
164 min-cost stype-cost))))))
165 ;; This used to return the *UNIVERSAL-TYPE* if no supertype was found,
166 ;; but that's too liberal: it's far too easy for the user to create
167 ;; a union type (which are excluded above), and then trick the compiler
168 ;; into trusting the union type... and finally ending up corrupting the
169 ;; heap once a bad object sneaks past the missing type check.
171 min-type
172 type)))))
186 \f
187 ;;;; checking strategy determination
189 ;;; Return the type we should test for when we really want to check
190 ;;; for TYPE. If type checking policy is "fast", then we return a
191 ;;; weaker type if it is easier to check. First we try the defined
192 ;;; type weakenings, then look for any predicate that is cheaper.
200 ;;; This is like VALUES-TYPES, only we mash any complex function types
201 ;;; to FUNCTION.
208 type))
209 res)
210 count)))
212 ;;; Switch to disable check complementing, for evaluation.
215 ;;; LVAR is an lvar we are doing a type check on and TYPES is a list
216 ;;; of types that we are checking its values against. If we have
217 ;;; proven that LVAR generates a fixed number of values, then for each
218 ;;; value, we check whether it is cheaper to then difference between
219 ;;; the proven type and the corresponding type in TYPES. If so, we opt
220 ;;; for a :HAIRY check with that test negated. Otherwise, we try to do
221 ;;; a simple test, and if that is impossible, we do a hairy test with
222 ;;; non-negated types. If true, FORCE-HAIRY forces a hairy type check.
228 and c in types
229 and a in original-types
230 and i from 0
233 c)
241 into hairy-res
242 collect cc into simple-res
251 ;;; Determines whether CAST's assertion is:
252 ;;; -- checkable by the back end (:SIMPLE), or
253 ;;; -- not checkable by the back end, but checkable via an explicit
254 ;;; test in type check conversion (:HAIRY), or
255 ;;; -- not reasonably checkable at all (:TOO-HAIRY).
256 ;;;
257 ;;; We may check only fixed number of values; in any case the number
258 ;;; of generated values is trusted. If we know the number of produced
259 ;;; values, all of them are checked; otherwise if we know the number
260 ;;; of consumed -- only they are checked; otherwise the check is not
261 ;;; performed.
262 ;;;
263 ;;; A type is simply checkable if all the type assertions have a
264 ;;; TYPE-CHECK-TEMPLATE. In this :SIMPLE case, the second value is a
265 ;;; list of the type restrictions specified for the leading positional
266 ;;; values.
267 ;;;
268 ;;; Old comment:
269 ;;;
270 ;;; We force a check to be hairy even when there are fixed values
271 ;;; if we are in a context where we may be forced to use the
272 ;;; unknown values convention anyway. This is because IR2tran can't
273 ;;; generate type checks for unknown values lvars but people could
274 ;;; still be depending on the check being done. We only care about
275 ;;; EXIT and RETURN (not MV-COMBINATION) since these are the only
276 ;;; contexts where the ultimate values receiver
277 ;;;
278 ;;; In the :HAIRY case, the second value is a list of triples of
279 ;;; the form:
280 ;;; (NOT-P TYPE ORIGINAL-TYPE)
281 ;;;
282 ;;; If true, the NOT-P flag indicates a test that the corresponding
283 ;;; value is *not* of the specified TYPE. ORIGINAL-TYPE is the type
284 ;;; asserted on this value in the lvar, for use in error
285 ;;; messages. When NOT-P is true, this will be different from TYPE.
286 ;;;
287 ;;; This allows us to take what has been proven about CAST's argument
288 ;;; type into consideration. If it is cheaper to test for the
289 ;;; difference between the derived type and the asserted type, then we
290 ;;; check for the negation of this type instead.
300 nil)
311 ;; we [almost] know how many values are produced
315 ;; backend checks only consumed values
317 n-required))
319 ;; exactly one value is consumed
331 force-hairy
332 n-required))))
335 ;; we know the number of consumed values
338 n-consumed
341 n-consumed
343 force-hairy
344 n-required))
348 ;;; Return T is the cast appears to be from the declaration of the callee,
349 ;;; and should be checked externally -- that is, by the callee and not the caller.
355 ;; The theory is that the type assertion is from a declaration on the
356 ;; callee, so the callee should be able to do the check. We want to
357 ;; let the callee do the check, because it is possible that by the
358 ;; time of call that declaration will be changed and we do not want
359 ;; to make people recompile all calls to a function when they were
360 ;; originally compiled with a bad declaration.
361 ;;
362 ;; ALMOST-IMMEDIATELY-USED-P ensures that we don't delegate casts
363 ;; that occur before nodes that can cause observable side effects --
364 ;; most commonly other non-external casts: so the order in which
365 ;; possible type errors are signalled matches with the evaluation
366 ;; order.
367 ;;
368 ;; FIXME: We should let more cases be handled by the callee then we
369 ;; currently do, see: https://bugs.launchpad.net/sbcl/+bug/309104
370 ;; This is not fixable quite here, though, because flow-analysis has
371 ;; deleted the LVAR of the cast by the time we get here, so there is
372 ;; no destination. Perhaps we should mark cases inserted by
373 ;; ASSERT-CALL-TYPE explicitly, and delete those whose destination is
374 ;; deemed unreachable?
379 ;;; Return true if CAST's value is an lvar whose type the back end is
380 ;;; likely to be able to check (see GENERATE-TYPE-CHECKS). Since we
381 ;;; don't know what template the back end is going to choose to
382 ;;; implement the continuation's DEST, we use a heuristic.
383 ;;;
384 ;;; We always return T unless nobody uses the value (the backend
385 ;;; cannot check unused LVAR chains).
386 ;;;
387 ;;; The logic used to be more complex, but most of the cases that used
388 ;;; to be checked here are now dealt with differently . FIXME: but
389 ;;; here's one we used to do, don't anymore, but could still benefit
390 ;;; from, if we reimplemented it (elsewhere):
391 ;;;
392 ;;; -- If the lvar is an argument to a known function that has
393 ;;; no IR2-CONVERT method or :FAST-SAFE templates that are
394 ;;; compatible with the call's type: return NIL.
395 ;;;
396 ;;; The code used to look like something like this:
397 ;;; ...
398 ;;; (:known
399 ;;; (let ((info (basic-combination-fun-info dest)))
400 ;;; (if (fun-info-ir2-convert info)
401 ;;; t
402 ;;; (dolist (template (fun-info-templates info) nil)
403 ;;; (when (eq (template-ltn-policy template)
404 ;;; :fast-safe)
405 ;;; (multiple-value-bind (val win)
406 ;;; (valid-fun-use dest (template-type template))
407 ;;; (when (or val (not win)) (return t)))))))))))))
408 ;;;
409 ;;; ADP says: It is still interesting. When we have a :SAFE template
410 ;;; and the type assertion is derived from the destination function
411 ;;; type, the check is unneccessary. We cannot return NIL here (the
412 ;;; whole function has changed its meaning, and here NIL *forces*
413 ;;; hairy check), but the functionality is interesting.
421 ;; Type specifiers handled by the general-purpose MAKE-TYPE-CHECK-FORM are often
422 ;; trivial enough to have an internal error number assigned to them that can be
423 ;; used in lieu of OBJECT-NOT-TYPE-ERROR. On x86-64 this saves 16 bytes: 1 word
424 ;; for the symbol in the function's constant area, a MOV instruction to load it,
425 ;; and an sc-offset in the error trap.
428 ;; read-time-eval so that during cold-init we can recreate the
429 ;; table using the target's sxhash function, but without relying
430 ;; on readiness of the type system for parsing/unparsing specifiers.
437 ;; This is effectively a compact read-only binned hashtable.
440 ;; Older architectures don't have a VOP that can emit an arbitrary
441 ;; primitive trap (see "compiler/generic/type-error" - and fix that)
448 entries)
449 hashtable))
460 ;; spec -> (count . primitive-p)
464 answer)))
466 ;;; Return a lambda form that we can convert to do a hairy type check
467 ;;; of the specified TYPES. TYPES is a list of the format returned by
468 ;;; LVAR-CHECK-TYPES in the :HAIRY case.
469 ;;;
470 ;;; Note that we don't attempt to check for required values being
471 ;;; unsupplied. Such checking is impossible to efficiently do at the
472 ;;; source level because our fixed-values conventions are optimized
473 ;;; for the common MV-BIND case.
477 'dummy
490 temps
491 types)
494 ;;; Splice in explicit type check code immediately before CAST. This
495 ;;; code receives the value(s) that were being passed to CAST-VALUE,
496 ;;; checks the type(s) of the value(s), then passes them further.
507 atype)
521 ;;; Check all possible arguments of CAST and emit type warnings for
522 ;;; those with type errors. If the value of USE is being used for a
523 ;;; variable binding, we figure out which one for source context. If
524 ;;; the value is a constant, we print it specially.
551 pos)))))))
554 :format-control
555 "~:[This~;~:*~A~] is not a ~<~%~9T~:;~S:~>~% ~S"
556 :format-arguments
561 :format-control
562 "~:[Result~;~:*~A~] is a ~S, ~<~%~9T~:;not a ~S.~>"
563 :format-arguments
567 ;;; Loop over all blocks in COMPONENT that have TYPE-CHECK set,
568 ;;; looking for CASTs with TYPE-CHECK T. We do two mostly unrelated
569 ;;; things: detect compile-time type errors and determine if and how
570 ;;; to do run-time type checks.
571 ;;;
572 ;;; If there is a compile-time type error, then we mark the CAST and
573 ;;; emit a warning if appropriate. This part loops over all the uses
574 ;;; of the continuation, since after we convert the check, the
575 ;;; :DELETED kind will inhibit warnings about the types of other uses.
576 ;;;
577 ;;; If the cast is too complex to be checked by the back end, or is
578 ;;; better checked with explicit code, then convert to an explicit
579 ;;; test. Assertions that can checked by the back end are passed
580 ;;; through. Assertions that can't be tested are flamed about and
581 ;;; marked as not needing to be checked.
582 ;;;
583 ;;; If we determine that a type check won't be done, then we set
584 ;;; TYPE-CHECK to :NO-CHECK. In the non-hairy cases, this is just to
585 ;;; prevent us from wasting time coming to the same conclusion again
586 ;;; on a later iteration. In the hairy case, we must indicate to LTN
587 ;;; that it must choose a safe implementation, since IR2 conversion
588 ;;; will choke on the check.
589 ;;;
590 ;;; The generation of the type checks is delayed until all the type
591 ;;; check decisions have been made because the generation of the type
592 ;;; checks creates new nodes whose derived types aren't always updated
593 ;;; which may lead to inappropriate template choices due to the
594 ;;; modification of argument types.
599 ;; CAST-EXTERNALLY-CHECKABLE-P wants the backward pass
607 ;; it is possible that NODE was marked :EXTERNAL by
608 ;; the previous pass
618 (:hairy
620 (:too-hairy
624 "type assertion too complex to check:~% ~S."