| blob | 7e0317b02f80e4d6cb79c454f99712159f33d9be |
1 ;;;; This file contains stuff for maintaining a database of special
2 ;;;; information about functions known to the compiler. This includes
3 ;;;; semantic information such as side effects and type inference
4 ;;;; functions as well as transforms and IR2 translators.
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.
19 ;;;; interfaces to defining macros
21 ;;; an IR1 transform
23 ;; the function type which enables this transform.
24 ;;
25 ;; (Note that declaring this :TYPE FUN-TYPE probably wouldn't
26 ;; work because some function types, like (SPECIFIER-TYPE 'FUNCTION0
27 ;; itself, are represented as BUILT-IN-TYPE, and at least as of
28 ;; sbcl-0.pre7.54 or so, that's inconsistent with being a
29 ;; FUN-TYPE.)
31 ;; the transformation function. Takes the COMBINATION node and
32 ;; returns a lambda expression, or THROWs out.
34 ;; T if we should emit a failure note even if SPEED=INHIBIT-WARNINGS.
36 ;; A function with NODE as an argument that checks wheteher the
37 ;; transform applies in its policy.
38 ;; It used to be checked in the FUNCTION body but it would produce
39 ;; notes about failed transformation due to types even though it
40 ;; wouldn't have been applied with the right types anyway,
41 ;; or if another transform could be applied with the right policy.
44 ;;; A transform inserted at the front of fun-info-transforms and stops
45 ;;; other from firing if it has a VOP that can do the job.
60 ;;; Grab the FUN-INFO and enter the function, replacing any old
61 ;;; one with the same type and note.
62 ;;; Argument order is: policy constraint, ftype constraint, consequent.
63 ;;; (think "qualifiers + specializers -> method")
73 ctype)))
74 transforms)))
82 ;; Put vop-transform at the front.
89 transforms))
91 :important important
95 name))
97 ;;; Make a FUN-INFO structure with the specified type, attributes
98 ;;; and optimizers.
100 &key derive-type optimizer result-arg
101 overwrite-fndb-silently
102 call-type-deriver
103 annotation
104 folder)
107 ;; unparse it, so SFUNCTION -> FUNCTION
109 ctype)))
112 inherit)
116 ;; This is handled as an error because it's generally a bad
117 ;; thing to blow away all the old optimization stuff. It's
118 ;; also a potential source of sneaky bugs:
119 ;; DEFKNOWN FOO
120 ;; DEFTRANSFORM FOO
121 ;; DEFKNOWN FOO ; possibly hidden inside some macroexpansion
122 ;; ; Now the DEFTRANSFORM doesn't exist in the target Lisp.
123 ;; However, it's continuable because it might be useful to do
124 ;; it when testing new optimization stuff interactively.
127 "~@<overwriting old FUN-INFO ~2I~_~S ~I~_for ~S~:>"
128 old-fun-info name)
150 :derive-type derive-type
151 :optimizer optimizer
152 :result-arg result-arg
153 :call-type-deriver call-type-deriver
154 :annotation annotation
158 location)
160 names)
162 \f
163 ;;; This macro should be the way that all implementation independent
164 ;;; information about functions is made known to the compiler.
165 ;;;
166 ;;; FIXME: The comment above suggests that perhaps some of my added
167 ;;; FTYPE declarations are in poor taste. Should I change my
168 ;;; declarations, or change the comment, or what?
169 ;;;
170 ;;; FIXME: DEFKNOWN is needed only at build-the-system time. Figure
171 ;;; out some way to keep it from appearing in the target system.
172 ;;;
173 ;;; Declare the function NAME to be a known function. We construct a
174 ;;; type specifier for the function by wrapping (FUNCTION ...) around
175 ;;; the ARG-TYPES and RESULT-TYPE. ATTRIBUTES is an unevaluated list
176 ;;; of boolean attributes of the function. See their description in
177 ;;; (!DEF-BOOLEAN-ATTRIBUTE IR1). NAME may also be a list of names, in
178 ;;; which case the same information is given to all the names. The
179 ;;; keywords specify the initial values for various optimizers that
180 ;;; the function might have.
183 #-sb-xc-host
195 ;; Needs to be supported by the call VOPs
210 name
212 ',type
216 ,@keys
227 positional ;; required and &optional
228 rest
229 key
230 returns)
237 arg-types
243 positional-annotation
244 rest-annotation
245 key-annotation
246 return-annotation)
249 inhibit-flushing))
251 proper-or-dotted-list proper-or-circular-list))))
267 type)))
274 pair)))
280 type)))
286 type))))
294 (,@required
301 key-annotation return-annotation)
307 ;;; Return the FUN-INFO for NAME or die trying.
311 \f
312 ;;;; generic type inference methods
317 found)))
331 global-type))
334 ;;; Derive the type to be the type of the xxx'th arg. This can normally
335 ;;; only be done when the result value is that argument.
351 ;; Preserve all the list types without dragging
352 ;; (cons (eql 10)) stuff in.
358 cons-type)
361 null-type)
363 list-type))))
365 ;;; Return a closure usable as a derive-type method for accessing the
366 ;;; N'th argument. If arg is a list, result is a list. If arg is a
367 ;;; vector, result is a vector with the same element type.
369 preserve-vector-type
370 string-designator)
387 type)
394 simplified)
395 simplified)))))))))
397 ;;; Derive the type to be the type specifier which is the Nth arg.
405 ;;; Derive the type to be the type specifier which is the Nth arg,
406 ;;; with the additional restriptions noted in the CLHS for STRING and
407 ;;; SIMPLE-STRING, defined to specialize on CHARACTER, and for VECTOR
408 ;;; (under the page for MAKE-SEQUENCE).
409 ;;; At present this is used to derive the output type of CONCATENATE,
410 ;;; MAKE-SEQUENCE, and MERGE. Two things seem slightly amiss:
411 ;;; 1. The sequence type actually produced might not be exactly that specified.
412 ;;; (TYPE-OF (MAKE-SEQUENCE '(AND (NOT SIMPLE-ARRAY) (VECTOR BIT)) 9))
413 ;;; => (SIMPLE-BIT-VECTOR 9)
414 ;;; 2. Because we *know* that a hairy array won't be produced,
415 ;;; why does derivation preserve the non-simpleness, if so specified?
426 lspecifier
432 lspecifier
439 ctype)
452 ctype))))))))))
466 null-type))
467 ;; (READ-elt stream nil <x>) returns (OR (EQL <x>) elt-type)
469 element-type)
470 ;; If eof-error is unsupplied, or was but couldn't be nil
471 element-type)))
474 unexceptional-type))))
476 ;;; Return MAX MIN
486 ;; This can deal with just enough hair to handle type STRING,
487 ;; but might be made to use GENERIC-ABSTRACT-TYPE-FUNCTION
488 ;; if we really want to be more clever.
502 ;; If type derivation were able to notice that non-simple arrays can
503 ;; be mutated (changing the type), we could safely use LVAR-TYPE on
504 ;; any vector type. But it doesn't notice.
505 ;; We could use LVAR-CONSERVATIVE-TYPE to get a conservative answer.
506 ;; However that's probably not an important use, so the above
507 ;; logic restricts itself to simple arrays.
511 ;;; This used to be done in DEFOPTIMIZER DERIVE-TYPE, but
512 ;;; ASSERT-CALL-TYPE already asserts the ARRAY type, so it gets an extra
513 ;;; assertion that may not get eliminated and requires extra work.
543 rank
544 'array-rank-limit
545 array-rank-limit)
548 set)
550 do
552 args)))
562 ;; All but the last argument should be proper lists
564 while next
565 do
567 arg