| blob | d091f381e4353a5d08f0cd787f297184ccc502c0 |
1 ;;;; This file implements the IR1 optimization phase of the compiler.
2 ;;;; IR1 optimization is a grab-bag of optimizations that don't make
3 ;;;; major changes to the block-level control flow and don't use flow
4 ;;;; analysis. These optimizations can mostly be classified as
5 ;;;; "meta-evaluation", but there is a sizable top-down component as
6 ;;;; well.
8 ;;;; This software is part of the SBCL system. See the README file for
9 ;;;; more information.
10 ;;;;
11 ;;;; This software is derived from the CMU CL system, which was
12 ;;;; written at Carnegie Mellon University and released into the
13 ;;;; public domain. The software is in the public domain and is
14 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
15 ;;;; files for more information.
18 \f
19 ;;;; interface for obtaining results of constant folding
21 ;;; Return true for an LVAR whose sole use is a reference to a
22 ;;; constant leaf.
28 ;; check for EQL types (but not singleton numeric types)
33 ;;; Return the constant value for an LVAR whose only use is a constant
34 ;;; node.
39 leaf)
48 \f
49 ;;;; interface for obtaining results of type inference
51 ;;; Our best guess for the type of this lvar's value. Note that this
52 ;;; may be VALUES or FUNCTION type, which cannot be passed as an
53 ;;; argument to the normal type operations. See LVAR-TYPE.
54 ;;;
55 ;;; The result value is cached in the LVAR-%DERIVED-TYPE slot. If the
56 ;;; slot is true, just return that value, otherwise recompute and
57 ;;; stash the value there.
67 res))
70 res)))
83 ;;; Return the derived type for LVAR's first value. This is guaranteed
84 ;;; not to be a VALUES or FUNCTION type.
89 ;;; LVAR-CONSERVATIVE-TYPE
90 ;;;
91 ;;; Certain types refer to the contents of an object, which can
92 ;;; change without type derivation noticing: CONS types and ARRAY
93 ;;; types suffer from this:
94 ;;;
95 ;;; (let ((x (the (cons fixnum fixnum) (cons a b))))
96 ;;; (setf (car x) c)
97 ;;; (+ (car x) (cdr x)))
98 ;;;
99 ;;; Python doesn't realize that the SETF CAR can change the type of X -- so we
100 ;;; cannot use LVAR-TYPE which gets the derived results. Worse, still, instead
101 ;;; of (SETF CAR) we might have a call to a user-defined function FOO which
102 ;;; does the same -- so there is no way to use the derived information in
103 ;;; general.
104 ;;;
105 ;;; So, the conservative option is to use the derived type if the leaf has
106 ;;; only a single ref -- in which case there cannot be a prior call that
107 ;;; mutates it. Otherwise we use the declared type or punt to the most general
108 ;;; type we know to be correct for sure.
112 ;; Recompute using NODE-CONSERVATIVE-TYPE instead of derived type if
113 ;; necessary -- picking off some easy cases up front.
115 ;; Can't use CSUBTYPEP!
118 derived-type)
122 derived-type)
128 derived-type)
132 derived-type))))
145 derived-values-type))
146 derived-values-type)))
152 type)
158 ;; ADJUST-ARRAY may change dimensions, but rank stays same.
159 :dimensions
162 old
164 ;; Complexity cannot change.
166 ;; Element type cannot change.
169 ;; Simple arrays cannot change at all.
170 type))
172 ;; If the type contains some CONS types, the conservative type contains all
173 ;; of them.
176 ;; Similarly for non-simple arrays -- it should be possible to preserve
177 ;; more information here, but really...
181 type)))
185 ;; Excluding T is necessary, because we do want type derivation to
186 ;; be able to narrow it down in case someone (most like a macro-expansion...)
187 ;; actually declares something as having type T.
188 nil)
190 ;; Covered by the next case as well, but this is a quick test.
191 t)
193 t)))
195 ;;; If LVAR is an argument of a function, return a type which the
196 ;;; function checks LVAR for.
205 ;; TODO: MV-COMBINATION
213 ;; FUN-TYPE might be (AND FUNCTION (SATISFIES ...)).
226 dest)))))
232 \f
233 ;;;; interface routines used by optimizers
243 ;;; This function is called by optimizers to indicate that something
244 ;;; interesting has happened to the value of LVAR. Optimizers must
245 ;;; make sure that they don't call for reoptimization when nothing has
246 ;;; happened, since optimization will fail to terminate.
247 ;;;
248 ;;; We clear any cached type for the lvar and set the reoptimize flags
249 ;;; on everything in sight.
259 ;; PREV may be missing.
278 ;;; Annotate NODE to indicate that its result has been proven to be
279 ;;; TYPEP to RTYPE. After IR1 conversion has happened, this is the
280 ;;; only correct way to supply information discovered about a node's
281 ;;; type. If you screw with the NODE-DERIVED-TYPE directly, then
282 ;;; information may be lost and reoptimization may not happen.
283 ;;;
284 ;;; What we do is intersect RTYPE with NODE's DERIVED-TYPE. If the
285 ;;; intersection is different from the old type, then we do a
286 ;;; REOPTIMIZE-LVAR on the NODE-LVAR.
299 "New inferred type ~S conflicts with old type:~
300 ~% ~S~%*** possible internal error? Please report this."
303 ;; If the new type consists of only one object, replace the
304 ;; node with a constant reference.
315 ;;; This is similar to DERIVE-NODE-TYPE, but asserts that it is an
316 ;;; error for LVAR's value not to be TYPEP to TYPE. We implement it
317 ;;; splitting off DEST a new CAST node; old LVAR will deliver values
318 ;;; to CAST. If we improve the assertion, we set TYPE-CHECK and
319 ;;; TYPE-ASSERTED to guarantee that the new assertion will be checked.
330 \f
331 ;;;; IR1-OPTIMIZE
333 ;;; Do one forward pass over COMPONENT, deleting unreachable blocks
334 ;;; and doing IR1 optimizations. We can ignore all blocks that don't
335 ;;; have the REOPTIMIZE flag set. If COMPONENT-REOPTIMIZE is true when
336 ;;; we are done, then another iteration would be beneficial.
342 for last-block = block
345 ;; We delete blocks when there is either no predecessor or the
346 ;; block is in a lambda that has been deleted. These blocks
347 ;; would eventually be deleted by DFO recomputation, but doing
348 ;; it here immediately makes the effect available to IR1
349 ;; optimization.
355 ;; Preserve the BLOCK-SUCC invariant that almost every block has
356 ;; one successor (and a block with DELETE-P set is an acceptable
357 ;; exception).
392 ;;; Loop over the nodes in BLOCK, acting on (and clearing) REOPTIMIZE
393 ;;; flags.
394 ;;;
395 ;;; Note that although they are cleared here, REOPTIMIZE flags might
396 ;;; still be set upon return from this function, meaning that further
397 ;;; optimization is wanted (as a consequence of optimizations we did).
400 ;; We clear the node and block REOPTIMIZE flags before doing the
401 ;; optimization, not after. This ensures that the node or block will
402 ;; be reoptimized if necessary.
406 ;; As above, we clear the node REOPTIMIZE flag before optimizing.
411 ;; With a COMBINATION, we call PROPAGATE-FUN-CHANGE whenever
412 ;; the function changes, and call IR1-OPTIMIZE-COMBINATION if
413 ;; any argument changes.
418 ;; KLUDGE: We leave the NODE-OPTIMIZE flag set going into
419 ;; IR1-OPTIMIZE-RETURN, since IR1-OPTIMIZE-RETURN wants to
420 ;; clear the flag itself. -- WHN 2002-02-02, quoting original
421 ;; CMU CL comments
427 ;; With an EXIT, we derive the node's type from the VALUE's
428 ;; type.
433 ;; PROPAGATE-FROM-SETS can do a better job if NODE-REOPTIMIZE
434 ;; is accurate till the node actually has been reoptimized.
442 ;;; Try to join with a successor block. If we succeed, we return true,
443 ;;; otherwise false.
450 ;; the successor has more than one predecessor;
452 ;; the successor is the current block (infinite loop);
454 ;; the next block has a different cleanup, and thus
455 ;; we may want to insert cleanup code between the
456 ;; two blocks at some point;
459 ;; the next block has a different home lambda, and
460 ;; thus the control transfer is a non-local exit.
463 ;; Stack analysis phase wants ENTRY to start a block...
469 ;; ... and a DX-allocator to end a block.
471 ;; FIXME: This is a partial workaround for bug 303.
473 nil)
476 t)))))
478 ;;; Join together two blocks. The code in BLOCK2 is moved into BLOCK1
479 ;;; and BLOCK2 is deleted from the DFO. We combine the optimize flags
480 ;;; for the two blocks so that any indicated optimization gets done.
513 ;;; Delete any nodes in BLOCK whose value is unused and which have no
514 ;;; side effects. We can delete sets of lexical variables when the set
515 ;;; variable has no references.
556 \f
557 ;;;; local call return type propagation
559 ;;; This function is called on RETURN nodes that have their REOPTIMIZE
560 ;;; flag set. It iterates over the uses of the RESULT, looking for
561 ;;; interesting stuff to update the TAIL-SET. If a use isn't a local
562 ;;; call, then we union its type together with the types of other such
563 ;;; uses. We assign to the RETURN-RESULT-TYPE the intersection of this
564 ;;; type with the RESULT's asserted type. We can make this
565 ;;; intersection now (potentially before type checking) because this
566 ;;; assertion on the result will eventually be checked (if
567 ;;; appropriate.)
568 ;;;
569 ;;; We call MAYBE-CONVERT-TAIL-LOCAL-CALL on each local non-MV
570 ;;; combination, which may change the successor of the call to be the
571 ;;; called function, and if so, checks if the call can become an
572 ;;; assignment. If we convert to an assignment, we abort, since the
573 ;;; RETURN has been deleted.
592 ;; (values-type-intersection
593 ;; (continuation-asserted-type result) ; FIXME -- APD, 2002-01-26
595 ;; )
596 ))
598 nil)
600 ;;; Do stuff to realize that something has changed about the value
601 ;;; delivered to a return node. Since we consider the return values of
602 ;;; all functions in the tail set to be equivalent, this amounts to
603 ;;; bringing the entire tail set up to date. We iterate over the
604 ;;; returns for all the functions in the tail set, reanalyzing them
605 ;;; all (not treating NODE specially.)
606 ;;;
607 ;;; When we are done, we check whether the new type is different from
608 ;;; the old TAIL-SET-TYPE. If so, we set the type and also reoptimize
609 ;;; all the lvars for references to functions in the tail set. This
610 ;;; will cause IR1-OPTIMIZE-COMBINATION to derive the new type as the
611 ;;; results of the calls.
615 :restart
635 \f
636 ;;;; IF optimization
638 ;;; If the test has multiple uses, replicate the node when possible.
639 ;;; Also check whether the predicate is known to be true or false,
640 ;;; deleting the IF node in favor of the appropriate branch when this
641 ;;; is the case.
672 ;;; Create a new copy of an IF node that tests the value of the node
673 ;;; USE. The test must have >1 use, and must be immediately used by
674 ;;; USE. NODE must be the only node in its block (implying that
675 ;;; block-start = if-test).
676 ;;;
677 ;;; This optimization has an effect semantically similar to the
678 ;;; source-to-source transformation:
679 ;;; (IF (IF A B C) D E) ==>
680 ;;; (IF A (IF B D E) (IF C D E))
681 ;;;
682 ;;; We clobber the NODE-SOURCE-PATH of both the original and the new
683 ;;; node so that dead code deletion notes will definitely not consider
684 ;;; either node to be part of the original source. One node might
685 ;;; become unreachable, resulting in a spurious note.
697 :consequent cblock
719 \f
720 ;;;; exit IR1 optimization
722 ;;; This function attempts to delete an exit node, returning true if
723 ;;; it deletes the block as a consequence:
724 ;;; -- If the exit is degenerate (has no ENTRY), then we don't do
725 ;;; anything, since there is nothing to be done.
726 ;;; -- If the exit node and its ENTRY have the same home lambda then
727 ;;; we know the exit is local, and can delete the exit. We change
728 ;;; uses of the Exit-Value to be uses of the original lvar,
729 ;;; then unlink the node. If the exit is to a TR context, then we
730 ;;; must do MERGE-TAIL-SETS on any local calls which delivered
731 ;;; their value to this exit.
732 ;;; -- If there is no value (as in a GO), then we skip the value
733 ;;; semantics.
734 ;;;
735 ;;; This function is also called by environment analysis, since it
736 ;;; wants all exits to be optimized even if normal optimization was
737 ;;; omitted.
749 \f
750 ;;;; combination IR1 optimization
752 ;;; Report as we try each transform?
753 #!+sb-show
761 "The return value of ~A should not be discarded."
764 ;;; Do IR1 optimizations on a COMBINATION node.
774 (:local
779 (:error
783 (:full
805 (:known
813 ;; If somebody is really sure that they want to modify
814 ;; constants, let them.
827 ;; KLUDGE: The next test could be made more sensitive,
828 ;; only suppressing constant-folding of functions with
829 ;; CALL attributes when they're actually passed
830 ;; function arguments. -- WHN 19990918
846 ;; First give the VM a peek at the call
850 (:direct
851 ;; The VM knows how to handle this.
852 )
853 (:transform
854 ;; The VM mostly knows how to handle this. We need
855 ;; to massage the call slightly, though.
857 (:default
858 ;; Let transforms have a crack at it.
860 #!+sb-show
866 #!+sb-show
881 ;;; If NODE doesn't return (i.e. return type is NIL), then terminate
882 ;;; the block there, and link it to the component tail.
883 ;;;
884 ;;; Except when called during IR1 convertion, we delete the
885 ;;; continuation if it has no other uses. (If it does have other uses,
886 ;;; we reoptimize.)
887 ;;;
888 ;;; Termination on the basis of a continuation type is
889 ;;; inhibited when:
890 ;;; -- The continuation is deleted (hence the assertion is spurious), or
891 ;;; -- We are in IR1 conversion (where THE assertions are subject to
892 ;;; weakening.) FIXME: Now THE assertions are not weakened, but new
893 ;;; uses can(?) be added later. -- APD, 2003-07-17
894 ;;;
895 ;;; Why do we need to consider LVAR type? -- APD, 2003-07-30
906 ;; Even if the combination will never return, don't terminate if this
907 ;; is the tail call of a XEP: doing that would inhibit TCO.
934 t))))
936 ;;; This is called both by IR1 conversion and IR1 optimization when
937 ;;; they have verified the type signature for the call, and are
938 ;;; wondering if something should be done to special-case the call. If
939 ;;; CALL is a call to a global function, then see whether it defined
940 ;;; or known:
941 ;;; -- If a DEFINED-FUN should be inline expanded, then convert
942 ;;; the expansion and change the call to call it. Expansion is
943 ;;; enabled if :INLINE or if SPACE=0. If the FUNCTIONAL slot is
944 ;;; true, we never expand, since this function has already been
945 ;;; converted. Local call analysis will duplicate the definition
946 ;;; if necessary. We claim that the parent form is LABELS for
947 ;;; context declarations, since we don't want it to be considered
948 ;;; a real global function.
949 ;;; -- If it is a known function, mark it as such by setting the KIND.
950 ;;;
951 ;;; We return the leaf referenced (NIL if not a leaf) and the
952 ;;; FUN-INFO assigned.
976 ;; Inline: if the function has already been converted at another call
977 ;; site in this component, we point this REF to the functional. If not,
978 ;; we convert the expansion.
979 ;;
980 ;; For :INLINE case local call analysis will copy the expansion later,
981 ;; but for :MAYBE-INLINE and NIL cases we only get one copy of the
982 ;; expansion per component.
983 ;;
984 ;; FIXME: We also convert in :INLINE & FUNCTIONAL-KIND case below. What
985 ;; is it for?
989 name
991 leaf
992 inlinep
994 ;; Allow backward references to this function from following
995 ;; forms. (Reused only if policy matches.)
1001 ;; Convert.
1007 ;; If we've already converted, change ref to the converted
1008 ;; functional.
1020 ;;; Check whether CALL satisfies TYPE. If so, apply the type to the
1021 ;;; call, and do MAYBE-TERMINATE-BLOCK and return the values of
1022 ;;; RECOGNIZE-KNOWN-CALL. If an error, set the combination kind and
1023 ;;; return NIL, NIL. If the type is just FUNCTION, then skip the
1024 ;;; syntax check, arg/result type processing, but still call
1025 ;;; RECOGNIZE-KNOWN-CALL, since the call might be to a known lambda,
1026 ;;; and that checking is done by local call analysis.
1033 ;; In the commonish case where the function has been defined
1034 ;; in another file, we only get FUNCTION for the type; but we
1035 ;; can check whether the current call is valid for the
1036 ;; existing definition, even if only to STYLE-WARN about it.
1040 :result-test nil
1046 :result-test nil
1047 ;; KLUDGE: Common Lisp is such a dynamic
1048 ;; language that all we can do here in
1049 ;; general is issue a STYLE-WARNING. It
1050 ;; would be nice to issue a full WARNING
1051 ;; in the special case of of type
1052 ;; mismatches within a compilation unit
1053 ;; (as in section 3.2.2.3 of the spec)
1054 ;; but at least as of sbcl-0.6.11, we
1055 ;; don't keep track of whether the
1056 ;; mismatched data came from the same
1057 ;; compilation unit, so we can't do that.
1058 ;; -- WHN 2001-02-11
1059 ;;
1060 ;; FIXME: Actually, I think we could
1061 ;; issue a full WARNING if the call
1062 ;; violates a DECLAIM FTYPE.
1072 ;;; This is called by IR1-OPTIMIZE when the function for a call has
1073 ;;; changed. If the call is local, we try to LET-convert it, and
1074 ;;; derive the result type. If it is a :FULL call, we validate it
1075 ;;; against the type, which recognizes known calls, does inline
1076 ;;; expansion, etc. If a call to a predicate in a non-conditional
1077 ;;; position or to a function with a source transform, then we
1078 ;;; reconvert the form to give IR1 another chance.
1085 (:local
1090 (:full
1096 call))
1104 predicate)
1118 \f
1119 ;;;; known function optimization
1121 ;;; Add a failed optimization note to FAILED-OPTIMZATIONS for NODE,
1122 ;;; FUN and ARGS. If there is already a note for NODE and TRANSFORM,
1123 ;;; replace it, otherwise add a new one.
1134 ;;; Attempt to transform NODE using TRANSFORM-FUNCTION, subject to the
1135 ;;; call type constraint TRANSFORM-TYPE. If we are inhibited from
1136 ;;; doing the transform for some reason and FLAME is true, then we
1137 ;;; make a note of the message in FAILED-OPTIMIZATIONS for IR1
1138 ;;; finalize to pick up. We return true if the transform failed, and
1139 ;;; thus further transformation should be attempted. We return false
1140 ;;; if either the transform succeeded or was aborted.
1160 (:none
1162 nil)
1163 (:aborted
1168 nil)
1169 (:failure
1175 t)
1176 (:delayed
1178 nil))))
1181 type
1185 t)
1187 t))))
1189 ;;; When we don't like an IR1 transform, we throw the severity/reason
1190 ;;; and args.
1191 ;;;
1192 ;;; GIVE-UP-IR1-TRANSFORM is used to throw out of an IR1 transform,
1193 ;;; aborting this attempt to transform the call, but admitting the
1194 ;;; possibility that this or some other transform will later succeed.
1195 ;;; If arguments are supplied, they are format arguments for an
1196 ;;; efficiency note.
1197 ;;;
1198 ;;; ABORT-IR1-TRANSFORM is used to throw out of an IR1 transform and
1199 ;;; force a normal call to the function at run time. No further
1200 ;;; optimizations will be attempted.
1201 ;;;
1202 ;;; DELAY-IR1-TRANSFORM is used to throw out of an IR1 transform, and
1203 ;;; delay the transform on the node until later. REASONS specifies
1204 ;;; when the transform will be later retried. The :OPTIMIZE reason
1205 ;;; causes the transform to be delayed until after the current IR1
1206 ;;; optimization pass. The :CONSTRAINT reason causes the transform to
1207 ;;; be delayed until after constraint propagation.
1208 ;;;
1209 ;;; FIXME: Now (0.6.11.44) that there are 4 variants of this (GIVE-UP,
1210 ;;; ABORT, DELAY/:OPTIMIZE, DELAY/:CONSTRAINT) and we're starting to
1211 ;;; do CASE operations on the various REASON values, it might be a
1212 ;;; good idea to go OO, representing the reasons by objects, using
1213 ;;; CLOS methods on the objects instead of CASE, and (possibly) using
1214 ;;; SIGNAL instead of THROW.
1231 ;;; Clear any delayed transform with no reasons - these should have
1232 ;;; been tried in the last pass. Then remove the reason from the
1233 ;;; delayed transform reasons, and if any become empty then set
1234 ;;; reoptimize flags for the node. Return true if any transforms are
1235 ;;; to be retried.
1251 reoptimize))
1253 ;;; Take the lambda-expression RES, IR1 convert it in the proper
1254 ;;; environment, and then install it as the function for the call
1255 ;;; NODE. We do local call analysis so that the new function is
1256 ;;; integrated into the control flow.
1257 ;;;
1258 ;;; We require the original function source name in order to generate
1259 ;;; a meaningful debug name for the lambda we set up. (It'd be
1260 ;;; possible to do this starting from debug names as well as source
1261 ;;; names, but as of sbcl-0.7.1.5, there was no need for this
1262 ;;; generality, since source names are always known to our callers.)
1268 ;; The internal variables of a transform are not going to be
1269 ;; interesting to the debugger, so there's no sense in
1270 ;; suppressing the substitution of variables with only one use
1271 ;; (the extra variables can slow down constraint propagation).
1272 ;;
1273 ;; This needs to be done before the WITH-IR1-ENVIRONMENT-FROM-NODE,
1274 ;; so that it will bind *LEXENV* to the right environment.
1287 res
1296 ;;; Replace a call to a foldable function of constant arguments with
1297 ;;; the result of evaluating the form. If there is an error during the
1298 ;;; evaluation, we give a warning and leave the call alone, making the
1299 ;;; call a :ERROR call.
1300 ;;;
1301 ;;; If there is more than one value, then we transform the call into a
1302 ;;; VALUES form.
1308 args
1309 call
1310 ;; Note: CMU CL had COMPILER-WARN here, and that
1311 ;; seems more natural, but it's probably not.
1312 ;;
1313 ;; It's especially not while bug 173 exists:
1314 ;; Expressions like
1315 ;; (COND (END
1316 ;; (UNLESS (OR UNSAFE? (<= END SIZE)))
1317 ;; ...))
1318 ;; can cause constant-folding TYPE-ERRORs (in
1319 ;; #'<=) when END can be proved to be NIL, even
1320 ;; though the code is perfectly legal and safe
1321 ;; because a NIL value of END means that the
1322 ;; #'<= will never be executed.
1323 ;;
1324 ;; Moreover, even without bug 173,
1325 ;; quite-possibly-valid code like
1326 ;; (COND ((NONINLINED-PREDICATE END)
1327 ;; (UNLESS (<= END SIZE))
1328 ;; ...))
1329 ;; (where NONINLINED-PREDICATE is something the
1330 ;; compiler can't do at compile time, but which
1331 ;; turns out to make the #'<= expression
1332 ;; unreachable when END=NIL) could cause errors
1333 ;; when the compiler tries to constant-fold (<=
1334 ;; END SIZE).
1335 ;;
1336 ;; So, with or without bug 173, it'd be
1337 ;; unnecessarily evil to do a full
1338 ;; COMPILER-WARNING (and thus return FAILURE-P=T
1339 ;; from COMPILE-FILE) for legal code, so we we
1340 ;; use a wimpier COMPILE-STYLE-WARNING instead.
1342 ;; On the other hand, for code we control, we
1343 ;; should be able to work around any bug
1344 ;; 173-related problems, and in particular we
1345 ;; want to be alerted to calls to our own
1346 ;; functions which aren't being folded away; a
1347 ;; COMPILER-WARNING is butch enough to stop the
1348 ;; SBCL build itself in its tracks.
1368 call
1372 fun-name))))))
1374 \f
1375 ;;;; local call optimization
1377 ;;; Propagate TYPE to LEAF and its REFS, marking things changed.
1378 ;;;
1379 ;;; If the leaf type is a function type, then just leave it alone, since TYPE
1380 ;;; is never going to be more specific than that (and TYPE-INTERSECTION would
1381 ;;; choke.)
1382 ;;;
1383 ;;; Also, if the type is one requiring special care don't touch it if the leaf
1384 ;;; has multiple references -- otherwise LVAR-CONSERVATIVE-TYPE is screwed.
1399 ;; KLUDGE: LET var substitution
1405 ;;; Iteration variable: exactly one SETQ of the form:
1406 ;;;
1407 ;;; (let ((var initial))
1408 ;;; ...
1409 ;;; (setq var (+ var step))
1410 ;;; ...)
1436 ;; Detect cases like (LOOP FOR 1.0 to 5.0 ...), where
1437 ;; the initial and the step are of different types,
1438 ;; and the step is less contagious.
1441 step-type))))
1480 :low low
1481 :high high
1484 "check for iteration variable reoptimization"
1494 ;;; Figure out the type of a LET variable that has sets. We compute
1495 ;;; the union of the INITIAL-TYPE and the types of all the set
1496 ;;; values and to a PROPAGATE-TO-REFS with this type.
1516 ;;; If a LET variable, find the initial value's type and do
1517 ;;; PROPAGATE-FROM-SETS. We also derive the VALUE's type as the node's
1518 ;;; type.
1534 ;;; Return true if the value of REF will always be the same (and is
1535 ;;; thus legal to substitute.)
1547 (:global-function
1554 ;;; If we have a non-set LET var with a single use, then (if possible)
1555 ;;; replace the variable reference's LVAR with the arg lvar.
1556 ;;;
1557 ;;; We change the REF to be a reference to NIL with unused value, and
1558 ;;; let it be flushed as dead code. A side effect of this substitution
1559 ;;; is to delete the variable.
1567 ;; Think about (LET ((A ...)) (IF ... A ...)): two
1568 ;; LVAR-USEs should not be met on one path. Another problem
1569 ;; is with dynamic-extent.
1572 ;; If the destinatation is dynamic extent, don't substitute unless
1573 ;; the source is as well.
1578 ;; we should not change lifetime of unknown values lvars
1590 ;; While CRETURN and EXIT nodes may be known-values,
1591 ;; they have their own complications, such as
1592 ;; substitution into CRETURN may create new tail calls.
1593 nil)
1596 t))
1602 ;; Really it is (EQ (LVAR-USES LVAR) REF):
1603 t)
1608 ;; KLUDGE: it should be (TYPE-CHECK 0)
1612 ;; FIXME
1613 t)
1621 t)))
1623 ;;; Delete a LET, removing the call and bind nodes, and warning about
1624 ;;; any unreferenced variables. Note that FLUSH-DEAD-CODE will come
1625 ;;; along right away and delete the REF and then the lambda, since we
1626 ;;; flush the FUN lvar.
1641 ;;; This function is called when one of the arguments to a LET
1642 ;;; changes. We look at each changed argument. If the corresponding
1643 ;;; variable is set, then we call PROPAGATE-FROM-SETS. Otherwise, we
1644 ;;; consider substituting for the variable, and also propagate
1645 ;;; derived-type information for the arg to all the VAR's refs.
1646 ;;;
1647 ;;; Substitution is inhibited when the arg leaf's derived type isn't a
1648 ;;; subtype of the argument's leaf type. This prevents type checking
1649 ;;; from being defeated, and also ensures that the best representation
1650 ;;; for the variable can be used.
1651 ;;;
1652 ;;; Substitution of individual references is inhibited if the
1653 ;;; reference is in a different component from the home. This can only
1654 ;;; happen with closures over top level lambda vars. In such cases,
1655 ;;; the references may have already been compiled, and thus can't be
1656 ;;; retroactively modified.
1657 ;;;
1658 ;;; If all of the variables are deleted (have no references) when we
1659 ;;; are done, then we delete the LET.
1660 ;;;
1661 ;;; Note that we are responsible for clearing the LVAR-REOPTIMIZE
1662 ;;; flags.
1677 ;; (NODE-DERIVED-TYPE USE) would
1678 ;; be better -- APD, 2003-05-15
1685 t)
1688 nil)))
1689 leaf var)))
1690 t)))))
1692 ;; Don't substitute single-ref variables on high-debug /
1693 ;; low speed, to improve the debugging experience.
1704 ;;; This function is called when one of the args to a non-LET local
1705 ;;; call changes. For each changed argument corresponding to an unset
1706 ;;; variable, we compute the union of the types across all calls and
1707 ;;; propagate this type information to the var's refs.
1708 ;;;
1709 ;;; If the function has an XEP, then we don't do anything, since we
1710 ;;; won't discover anything.
1711 ;;;
1712 ;;; We can clear the LVAR-REOPTIMIZE flags for arguments in all calls
1713 ;;; corresponding to changed arguments in CALL, since the only use in
1714 ;;; IR1 optimization of the REOPTIMIZE flag for local call args is
1715 ;;; right here.
1727 vars))
1743 union)))))
1746 and type in union
1750 \f
1751 ;;;; multiple values optimization
1753 ;;; Do stuff to notice a change to a MV combination node. There are
1754 ;;; two main branches here:
1755 ;;; -- If the call is local, then it is already a MV let, or should
1756 ;;; become one. Note that although all :LOCAL MV calls must eventually
1757 ;;; be converted to :MV-LETs, there can be a window when the call
1758 ;;; is local, but has not been LET converted yet. This is because
1759 ;;; the entry-point lambdas may have stray references (in other
1760 ;;; entry points) that have not been deleted yet.
1761 ;;; -- The call is full. This case is somewhat similar to the non-MV
1762 ;;; combination optimization: we propagate return type information and
1763 ;;; notice non-returning calls. We also have an optimization
1764 ;;; which tries to convert MV-CALLs into MV-binds.
1767 (:local
1776 (:full
1799 ;;; Propagate derived type info from the values lvar to the vars.
1806 n-vars)))
1808 and type in types
1815 ;;; If possible, convert a general MV call to an MV-BIND. We can do
1816 ;;; this if:
1817 ;;; -- The call has only one argument, and
1818 ;;; -- The function has a known fixed number of arguments, or
1819 ;;; -- The argument yields a known fixed number of values.
1820 ;;;
1821 ;;; What we do is change the function in the MV-CALL to be a lambda
1822 ;;; that "looks like an MV bind", which allows
1823 ;;; IR1-OPTIMIZE-MV-COMBINATION to notice that this call can be
1824 ;;; converted (the next time around.) This new lambda just calls the
1825 ;;; actual function with the MV-BIND variables as arguments. Note that
1826 ;;; this new MV bind is not let-converted immediately, as there are
1827 ;;; going to be stray references from the entry-point functions until
1828 ;;; they get deleted.
1829 ;;;
1830 ;;; In order to avoid loss of argument count checking, we only do the
1831 ;;; transformation according to a known number of expected argument if
1832 ;;; safety is unimportant. We can always convert if we know the number
1833 ;;; of actual values, since the normal call that we build will still
1834 ;;; do any appropriate argument count checking.
1835 ;;;
1836 ;;; We only attempt the transformation if the called function is a
1837 ;;; constant reference. This allows us to just splice the leaf into
1838 ;;; the new function, instead of trying to somehow bind the function
1839 ;;; expression. The leaf must be constant because we are evaluating it
1840 ;;; again in a different place. This also has the effect of squelching
1841 ;;; multiple warnings when there is an argument count error.
1863 "MULTIPLE-VALUE-CALL with ~R values when the function expects ~
1864 at least ~R."
1865 total-nvals min)
1870 "MULTIPLE-VALUE-CALL with ~R values when the function expects ~
1871 at most ~R."
1872 total-nvals max)
1879 min)
1898 ;;; If we see:
1899 ;;; (multiple-value-bind
1900 ;;; (x y)
1901 ;;; (values xx yy)
1902 ;;; ...)
1903 ;;; Convert to:
1904 ;;; (let ((x xx)
1905 ;;; (y yy))
1906 ;;; ...)
1907 ;;;
1908 ;;; What we actually do is convert the VALUES combination into a
1909 ;;; normal LET combination calling the original :MV-LET lambda. If
1910 ;;; there are extra args to VALUES, discard the corresponding
1911 ;;; lvars. If there are insufficient args, insert references to NIL.
1934 for prev = node-prev then ctran
1940 use ctran))
1956 t)))
1958 ;;; If we see:
1959 ;;; (values-list (list x y z))
1960 ;;;
1961 ;;; Convert to:
1962 ;;; (values x y z)
1963 ;;;
1964 ;;; In implementation, this is somewhat similar to
1965 ;;; CONVERT-MV-BIND-TO-LET. We grab the args of LIST and make them
1966 ;;; args of the VALUES-LIST call, flushing the old argument lvar
1967 ;;; (allowing the LIST to be flushed.)
1968 ;;;
1969 ;;; FIXME: Thus we lose possible type assertions on (LIST ...).
1976 ;; FIXME: VALUES might not satisfy an assertion on NODE-LVAR.
1987 t)))
1989 ;;; If VALUES appears in a non-MV context, then effectively convert it
1990 ;;; to a PROG1. This allows the computation of the additional values
1991 ;;; to become dead code.
2003 val))
2004 nil))
2006 ;;; TODO:
2007 ;;; - CAST chains;
2031 lvar)
2032 ;; Pathwise removing of CAST
2035 next-block)
2063 ;; FIXME: Do it in one step.
2065 value
2071 ;; FIXME: Derived type.
2075 ;; KLUDGE: FILTER-LVAR does not work for non-returning
2076 ;; functions, so we declare the return type of
2077 ;; %COMPILE-TIME-TYPE-ERROR to be * and derive the real type
2078 ;; here.
2082 ;; FIXME: Is it necessary?