| blob | 5faaed2abf4e0ac09e34d97f3de473edca77448c |
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 ;; string used in efficiency notes
36 ;; T if we should emit a failure note even if SPEED=INHIBIT-WARNINGS.
41 ;;; Grab the FUN-INFO and enter the function, replacing any old
42 ;;; one with the same type and note.
45 *)
46 %deftransform))
65 name))
67 ;;; Make a FUN-INFO structure with the specified type, attributes
68 ;;; and optimizers.
77 *)
78 %defknown))
80 &key derive-type optimizer destroyed-constant-args result-arg
81 overwrite-fndb-silently
82 foldable-call-check
83 callable-check)
89 ;; This is handled as an error because it's generally a bad
90 ;; thing to blow away all the old optimization stuff. It's
91 ;; also a potential source of sneaky bugs:
92 ;; DEFKNOWN FOO
93 ;; DEFTRANSFORM FOO
94 ;; DEFKNOWN FOO ; possibly hidden inside some macroexpansion
95 ;; ; Now the DEFTRANSFORM doesn't exist in the target Lisp.
96 ;; However, it's continuable because it might be useful to do
97 ;; it when testing new optimization stuff interactively.
99 "~@<overwriting old FUN-INFO ~2I~_~S ~I~_for ~S~:>"
100 old-fun-info name))))
106 :derive-type derive-type
107 :optimizer optimizer
108 :destroyed-constant-args destroyed-constant-args
109 :result-arg result-arg
110 :foldable-call-check foldable-call-check
114 location)
116 names)
118 ;;; Return the FUN-INFO for NAME or die trying.
122 \f
123 ;;;; generic type inference methods
125 ;;; Derive the type to be the type of the xxx'th arg. This can normally
126 ;;; only be done when the result value is that argument.
136 ;;; Derive the result type according to the float contagion rules, but
137 ;;; always return a float. This is used for irrational functions that
138 ;;; preserve realness of their arguments.
145 ;;; Return a closure usable as a derive-type method for accessing the
146 ;;; N'th argument. If arg is a list, result is a list. If arg is a
147 ;;; vector, result is a vector with the same element type.
159 ltype))))))))
161 ;;; Derive the type to be the type specifier which is the Nth arg.
169 ;;; Derive the type to be the type specifier which is the Nth arg,
170 ;;; with the additional restriptions noted in the CLHS for STRING and
171 ;;; SIMPLE-STRING, defined to specialize on CHARACTER, and for VECTOR
172 ;;; (under the page for MAKE-SEQUENCE).
173 ;;; At present this is used to derive the output type of CONCATENATE,
174 ;;; MAKE-SEQUENCE, and MERGE. Two things seem slightly amiss:
175 ;;; 1. The sequence type actually produced might not be exactly that specified.
176 ;;; (TYPE-OF (MAKE-SEQUENCE '(AND (NOT SIMPLE-ARRAY) (VECTOR BIT)) 9))
177 ;;; => (SIMPLE-BIT-VECTOR 9)
178 ;;; 2. Because we *know* that a hairy array won't be produced,
179 ;;; why does derivation preserve the non-simpleness, if so specified?
190 lspecifier
196 lspecifier
203 ctype)
216 ctype))))))))))
223 ;;; FIXME: bad name (first because it uses 1-based indexing; second
224 ;;; because it doesn't get the nth constant arguments)
237 ;;; FIXME: a number of the sequence functions not only do not destroy
238 ;;; their argument if it is empty, but also leave it alone if :start
239 ;;; and :end bound a null sequence, or if :count is 0. This test is a
240 ;;; bit complicated to implement, verging on the impossible, but for
241 ;;; extra points (fill #\1 "abc" :start 0 :end 0) should not cause a
242 ;;; warning.
270 null-type))
271 ;; (READ-elt stream nil <x>) returns (OR (EQL <x>) elt-type)
273 element-type)
274 ;; If eof-error is unsupplied, or was but couldn't be nil
275 element-type)))
278 unexceptional-type))))
282 ;; Could possibly constrain the result more highly if
283 ;; the :start/:end were provided and of known types.
285 ;; This can deal with just enough hair to handle type STRING,
286 ;; but might be made to use GENERIC-ABSTRACT-TYPE-FUNCTION
287 ;; if we really want to be more clever.
294 '*))
298 ;; If type derivation were able to notice that non-simple arrays can
299 ;; be mutated (changing the type), we could safely use LVAR-TYPE on
300 ;; any vector type. But it doesn't notice.
301 ;; We could use LVAR-CONSERVATIVE-TYPE to get a conservative answer.
302 ;; However that's probably not an important use, so the above
303 ;; logic restricts itself to simple arrays.