| blob | f9e5c08eabb21ac268f91a47159d4b337442bc45 |
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 and singleton numeric types
31 ;;; Same as above except for EQL types
38 ;;; Return the constant value for an LVAR whose only use is a constant
39 ;;; node.
44 leaf)
51 value))))
52 \f
53 ;;;; interface for obtaining results of type inference
55 ;;; Our best guess for the type of this lvar's value. Note that this
56 ;;; may be VALUES or FUNCTION type, which cannot be passed as an
57 ;;; argument to the normal type operations. See LVAR-TYPE.
58 ;;;
59 ;;; The result value is cached in the LVAR-%DERIVED-TYPE slot. If the
60 ;;; slot is true, just return that value, otherwise recompute and
61 ;;; stash the value there.
71 res))
74 res)))
87 ;;; Return the derived type for LVAR's first value. This is guaranteed
88 ;;; not to be a VALUES or FUNCTION type.
93 ;;; LVAR-CONSERVATIVE-TYPE
94 ;;;
95 ;;; Certain types refer to the contents of an object, which can
96 ;;; change without type derivation noticing: CONS types and ARRAY
97 ;;; types suffer from this:
98 ;;;
99 ;;; (let ((x (the (cons fixnum fixnum) (cons a b))))
100 ;;; (setf (car x) c)
101 ;;; (+ (car x) (cdr x)))
102 ;;;
103 ;;; Python doesn't realize that the SETF CAR can change the type of X -- so we
104 ;;; cannot use LVAR-TYPE which gets the derived results. Worse, still, instead
105 ;;; of (SETF CAR) we might have a call to a user-defined function FOO which
106 ;;; does the same -- so there is no way to use the derived information in
107 ;;; general.
108 ;;;
109 ;;; So, the conservative option is to use the derived type if the leaf has
110 ;;; only a single ref -- in which case there cannot be a prior call that
111 ;;; mutates it. Otherwise we use the declared type or punt to the most general
112 ;;; type we know to be correct for sure.
116 ;; Recompute using NODE-CONSERVATIVE-TYPE instead of derived type if
117 ;; necessary -- picking off some easy cases up front.
119 ;; Can't use CSUBTYPEP!
122 derived-type)
126 derived-type)
132 derived-type)
136 derived-type))))
149 derived-values-type))
150 derived-values-type)))
156 type)
162 ;; ADJUST-ARRAY may change dimensions, but rank stays same.
165 old
167 ;; Complexity cannot change.
169 ;; Element type cannot change.
172 ;; Simple arrays cannot change at all.
173 type))
175 ;; Conservative union type is an union of conservative types.
180 ;; Catch-all.
181 ;;
182 ;; If the type contains some CONS types, the conservative type contains all
183 ;; of them.
186 ;; Similarly for non-simple arrays -- it should be possible to preserve
187 ;; more information here, but really...
191 type)))
195 ;; Excluding T is necessary, because we do want type derivation to
196 ;; be able to narrow it down in case someone (most like a macro-expansion...)
197 ;; actually declares something as having type T.
198 nil)
200 ;; Covered by the next case as well, but this is a quick test.
201 t)
203 t)))
205 ;;; If LVAR is an argument of a function, return a type which the
206 ;;; function checks LVAR for.
215 ;; TODO: MV-COMBINATION
223 ;; FUN-TYPE might be (AND FUNCTION (SATISFIES ...)).
236 dest)))))
242 \f
243 ;;;; interface routines used by optimizers
253 ;;; This function is called by optimizers to indicate that something
254 ;;; interesting has happened to the value of LVAR. Optimizers must
255 ;;; make sure that they don't call for reoptimization when nothing has
256 ;;; happened, since optimization will fail to terminate.
257 ;;;
258 ;;; We clear any cached type for the lvar and set the reoptimize flags
259 ;;; on everything in sight.
269 ;; PREV may be missing.
288 ;;; Annotate NODE to indicate that its result has been proven to be
289 ;;; TYPEP to RTYPE. After IR1 conversion has happened, this is the
290 ;;; only correct way to supply information discovered about a node's
291 ;;; type. If you screw with the NODE-DERIVED-TYPE directly, then
292 ;;; information may be lost and reoptimization may not happen.
293 ;;;
294 ;;; What we do is intersect RTYPE with NODE's DERIVED-TYPE. If the
295 ;;; intersection is different from the old type, then we do a
296 ;;; REOPTIMIZE-LVAR on the NODE-LVAR.
302 initial-type)))
313 "New inferred type ~S conflicts with old type:~
314 ~% ~S~%*** possible internal error? Please report this."
317 ;; If the new type consists of only one object, replace the
318 ;; node with a constant reference.
329 ;;; This is similar to DERIVE-NODE-TYPE, but asserts that it is an
330 ;;; error for LVAR's value not to be TYPEP to TYPE. We implement it
331 ;;; splitting off DEST a new CAST node; old LVAR will deliver values
332 ;;; to CAST. If we improve the assertion, we set TYPE-CHECK and
333 ;;; TYPE-ASSERTED to guarantee that the new assertion will be checked.
342 t))))
344 \f
345 ;;;; IR1-OPTIMIZE
347 ;;; Do one forward pass over COMPONENT, deleting unreachable blocks
348 ;;; and doing IR1 optimizations. We can ignore all blocks that don't
349 ;;; have the REOPTIMIZE flag set. If COMPONENT-REOPTIMIZE is true when
350 ;;; we are done, then another iteration would be beneficial.
356 for last-block = block
359 ;; We delete blocks when there is either no predecessor or the
360 ;; block is in a lambda that has been deleted. These blocks
361 ;; would eventually be deleted by DFO recomputation, but doing
362 ;; it here immediately makes the effect available to IR1
363 ;; optimization.
369 ;; Preserve the BLOCK-SUCC invariant that almost every block has
370 ;; one successor (and a block with DELETE-P set is an acceptable
371 ;; exception).
406 ;;; Loop over the nodes in BLOCK, acting on (and clearing) REOPTIMIZE
407 ;;; flags.
408 ;;;
409 ;;; Note that although they are cleared here, REOPTIMIZE flags might
410 ;;; still be set upon return from this function, meaning that further
411 ;;; optimization is wanted (as a consequence of optimizations we did).
414 ;; We clear the node and block REOPTIMIZE flags before doing the
415 ;; optimization, not after. This ensures that the node or block will
416 ;; be reoptimized if necessary.
420 ;; As above, we clear the node REOPTIMIZE flag before optimizing.
425 ;; With a COMBINATION, we call PROPAGATE-FUN-CHANGE whenever
426 ;; the function changes, and call IR1-OPTIMIZE-COMBINATION if
427 ;; any argument changes.
432 ;; KLUDGE: We leave the NODE-OPTIMIZE flag set going into
433 ;; IR1-OPTIMIZE-RETURN, since IR1-OPTIMIZE-RETURN wants to
434 ;; clear the flag itself. -- WHN 2002-02-02, quoting original
435 ;; CMU CL comments
441 ;; With an EXIT, we derive the node's type from the VALUE's
442 ;; type.
447 ;; PROPAGATE-FROM-SETS can do a better job if NODE-REOPTIMIZE
448 ;; is accurate till the node actually has been reoptimized.
456 ;;; Try to join with a successor block. If we succeed, we return true,
457 ;;; otherwise false.
464 ;; the successor has more than one predecessor;
466 ;; the successor is the current block (infinite loop);
468 ;; the next block has a different cleanup, and thus
469 ;; we may want to insert cleanup code between the
470 ;; two blocks at some point;
473 ;; the next block has a different home lambda, and
474 ;; thus the control transfer is a non-local exit.
477 ;; Stack analysis phase wants ENTRY to start a block...
483 ;; ... and a DX-allocator to end a block.
485 ;; FIXME: This is a partial workaround for bug 303.
487 nil)
490 t)))))
492 ;;; Join together two blocks. The code in BLOCK2 is moved into BLOCK1
493 ;;; and BLOCK2 is deleted from the DFO. We combine the optimize flags
494 ;;; for the two blocks so that any indicated optimization gets done.
527 ;;; Delete any nodes in BLOCK whose value is unused and which have no
528 ;;; side effects. We can delete sets of lexical variables when the set
529 ;;; variable has no references.
575 victim)
576 \f
577 ;;;; local call return type propagation
579 ;;; This function is called on RETURN nodes that have their REOPTIMIZE
580 ;;; flag set. It iterates over the uses of the RESULT, looking for
581 ;;; interesting stuff to update the TAIL-SET. If a use isn't a local
582 ;;; call, then we union its type together with the types of other such
583 ;;; uses. We assign to the RETURN-RESULT-TYPE the intersection of this
584 ;;; type with the RESULT's asserted type. We can make this
585 ;;; intersection now (potentially before type checking) because this
586 ;;; assertion on the result will eventually be checked (if
587 ;;; appropriate.)
588 ;;;
589 ;;; We call MAYBE-CONVERT-TAIL-LOCAL-CALL on each local non-MV
590 ;;; combination, which may change the successor of the call to be the
591 ;;; called function, and if so, checks if the call can become an
592 ;;; assignment. If we convert to an assignment, we abort, since the
593 ;;; RETURN has been deleted.
612 ;; (values-type-intersection
613 ;; (continuation-asserted-type result) ; FIXME -- APD, 2002-01-26
615 ;; )
616 ))
618 nil)
620 ;;; Do stuff to realize that something has changed about the value
621 ;;; delivered to a return node. Since we consider the return values of
622 ;;; all functions in the tail set to be equivalent, this amounts to
623 ;;; bringing the entire tail set up to date. We iterate over the
624 ;;; returns for all the functions in the tail set, reanalyzing them
625 ;;; all (not treating NODE specially.)
626 ;;;
627 ;;; When we are done, we check whether the new type is different from
628 ;;; the old TAIL-SET-TYPE. If so, we set the type and also reoptimize
629 ;;; all the lvars for references to functions in the tail set. This
630 ;;; will cause IR1-OPTIMIZE-COMBINATION to derive the new type as the
631 ;;; results of the calls.
635 :restart
655 \f
656 ;;;; IF optimization
658 ;;; Utility: return T if both argument cblocks are equivalent. For now,
659 ;;; detect only blocks that read the same leaf into the same lvar, and
660 ;;; continue to the same block.
673 ;;; Check whether the predicate is known to be true or false,
674 ;;; deleting the IF node in favor of the appropriate branch when this
675 ;;; is the case.
676 ;;; Similarly, when both branches are equivalent, branch directly to either
677 ;;; of them.
678 ;;; Also, if the test has multiple uses, replicate the node when possible...
679 ;;; in fact, splice in direct jumps to the right branch if possible.
691 alternative)
693 consequent)
696 alternative))))
704 ;; When we know that we only have a single successor, kill the victim
705 ;; ... unless the victim and the remaining successor are the same.
714 ;; When if/if conversion would leave (if ... (if nil ...)) or
715 ;; (if ... (if not-nil ...)), splice the correct successor right
716 ;; in.
735 ;; only one use left. Just kill the now-useless
736 ;; branch to avoid spurious code deletion notes.
739 node test block
745 ;; Finally, duplicate EQ-nil tests
752 ;; leave the last use as is, instead of replacing
753 ;; the (singly-referenced) CIF node with a duplicate.
756 ;;; Create a new copy of an IF node that tests the value of the node
757 ;;; USE. The test must have >1 use, and must be immediately used by
758 ;;; USE. NODE must be the only node in its block (implying that
759 ;;; block-start = if-test).
760 ;;;
761 ;;; This optimization has an effect semantically similar to the
762 ;;; source-to-source transformation:
763 ;;; (IF (IF A B C) D E) ==>
764 ;;; (IF A (IF B D E) (IF C D E))
765 ;;;
766 ;;; We clobber the NODE-SOURCE-PATH of both the original and the new
767 ;;; node so that dead code deletion notes will definitely not consider
768 ;;; either node to be part of the original source. One node might
769 ;;; become unreachable, resulting in a spurious note.
781 :consequent cblock
803 \f
804 ;;;; exit IR1 optimization
806 ;;; This function attempts to delete an exit node, returning true if
807 ;;; it deletes the block as a consequence:
808 ;;; -- If the exit is degenerate (has no ENTRY), then we don't do
809 ;;; anything, since there is nothing to be done.
810 ;;; -- If the exit node and its ENTRY have the same home lambda then
811 ;;; we know the exit is local, and can delete the exit. We change
812 ;;; uses of the Exit-Value to be uses of the original lvar,
813 ;;; then unlink the node. If the exit is to a TR context, then we
814 ;;; must do MERGE-TAIL-SETS on any local calls which delivered
815 ;;; their value to this exit.
816 ;;; -- If there is no value (as in a GO), then we skip the value
817 ;;; semantics.
818 ;;;
819 ;;; This function is also called by environment analysis, since it
820 ;;; wants all exits to be optimized even if normal optimization was
821 ;;; omitted.
831 ;; We can't simply use DELETE-FILTER to unlink the node
832 ;; and substitute some LVAR magic, as this can confuse the
833 ;; stack analysis if there's another EXIT to the same
834 ;; continuation. Instead, we fabricate a new block (in
835 ;; the same lexenv as the ENTRY, so it can't be merged
836 ;; backwards), insert a gimmicked CAST node to link up the
837 ;; LVAR holding the value being returned to the LVAR which
838 ;; is expecting to accept the value, thus placing the
839 ;; return value where it needs to be while still providing
840 ;; the hook required for stack analysis.
841 ;; -- AJB, 2014-Mar-03
846 (%make-cast
849 :value value
853 ;; We only expect a single successor to EXIT-BLOCK,
854 ;; because it contains an EXIT node (which must end its
855 ;; block) and the only blocks that have more than once
856 ;; successor are those with IF nodes (which also must
857 ;; end their blocks). Still, just to be sure, we use a
858 ;; construct that guarantees an error if this
859 ;; expectation is violated.
864 ;; Finish creating the new block.
868 ;; Link the new block into the control sequence.
873 ;; Finish re-pointing the value-holding LVAR to the
874 ;; CAST node.
879 ;; Register the CAST node as providing a value to the
880 ;; LVAR for the continuation.
884 ;; Remove the EXIT node.
887 ;; And, because we created a new block, we need to
888 ;; force component reanalysis (to assign a DFO number
889 ;; to the block if nothing else).
893 \f
894 ;;;; combination IR1 optimization
896 ;;; Report as we try each transform?
897 #!+sb-show
905 "The return value of ~A should not be discarded."
908 ;;; Do IR1 optimizations on a COMBINATION node.
918 (:local
923 (:error
927 (:full
950 ;; Check against the DEFINED-TYPE unless TYPE is already good.
960 (:known
968 ;; If somebody is really sure that they want to modify
969 ;; constants, let them.
982 ;; KLUDGE: The next test could be made more sensitive,
983 ;; only suppressing constant-folding of functions with
984 ;; CALL attributes when they're actually passed
985 ;; function arguments. -- WHN 19990918
1005 ;; First give the VM a peek at the call
1009 (:direct
1010 ;; The VM knows how to handle this.
1011 )
1012 (:transform
1013 ;; The VM mostly knows how to handle this. We need
1014 ;; to massage the call slightly, though.
1017 ;; Let transforms have a crack at it.
1019 #!+sb-show
1025 #!+sb-show
1040 ;;; If NODE doesn't return (i.e. return type is NIL), then terminate
1041 ;;; the block there, and link it to the component tail.
1042 ;;;
1043 ;;; Except when called during IR1 convertion, we delete the
1044 ;;; continuation if it has no other uses. (If it does have other uses,
1045 ;;; we reoptimize.)
1046 ;;;
1047 ;;; Termination on the basis of a continuation type is
1048 ;;; inhibited when:
1049 ;;; -- The continuation is deleted (hence the assertion is spurious), or
1050 ;;; -- We are in IR1 conversion (where THE assertions are subject to
1051 ;;; weakening.) FIXME: Now THE assertions are not weakened, but new
1052 ;;; uses can(?) be added later. -- APD, 2003-07-17
1053 ;;;
1054 ;;; Why do we need to consider LVAR type? -- APD, 2003-07-30
1065 ;; Even if the combination will never return, don't terminate if this
1066 ;; is the tail call of a XEP: doing that would inhibit TCO.
1093 t))))
1095 ;;; This is called both by IR1 conversion and IR1 optimization when
1096 ;;; they have verified the type signature for the call, and are
1097 ;;; wondering if something should be done to special-case the call. If
1098 ;;; CALL is a call to a global function, then see whether it defined
1099 ;;; or known:
1100 ;;; -- If a DEFINED-FUN should be inline expanded, then convert
1101 ;;; the expansion and change the call to call it. Expansion is
1102 ;;; enabled if :INLINE or if SPACE=0. If the FUNCTIONAL slot is
1103 ;;; true, we never expand, since this function has already been
1104 ;;; converted. Local call analysis will duplicate the definition
1105 ;;; if necessary. We claim that the parent form is LABELS for
1106 ;;; context declarations, since we don't want it to be considered
1107 ;;; a real global function.
1108 ;;; -- If it is a known function, mark it as such by setting the KIND.
1109 ;;;
1110 ;;; We return the leaf referenced (NIL if not a leaf) and the
1111 ;;; FUN-INFO assigned.
1135 ;; Inline: if the function has already been converted at another call
1136 ;; site in this component, we point this REF to the functional. If not,
1137 ;; we convert the expansion.
1138 ;;
1139 ;; For :INLINE case local call analysis will copy the expansion later,
1140 ;; but for :MAYBE-INLINE and NIL cases we only get one copy of the
1141 ;; expansion per component.
1142 ;;
1143 ;; FIXME: We also convert in :INLINE & FUNCTIONAL-KIND case below. What
1144 ;; is it for?
1148 name
1150 leaf
1151 inlinep
1153 ;; Allow backward references to this function from following
1154 ;; forms. (Reused only if policy matches.)
1160 ;; Convert.
1166 ;; If we've already converted, change ref to the converted
1167 ;; functional.
1179 ;;; Check whether CALL satisfies TYPE. If so, apply the type to the
1180 ;;; call, and do MAYBE-TERMINATE-BLOCK and return the values of
1181 ;;; RECOGNIZE-KNOWN-CALL. If an error, set the combination kind and
1182 ;;; return NIL, NIL. If the type is just FUNCTION, then skip the
1183 ;;; syntax check, arg/result type processing, but still call
1184 ;;; RECOGNIZE-KNOWN-CALL, since the call might be to a known lambda,
1185 ;;; and that checking is done by local call analysis.
1194 ;; Using the defined-type too early is a bit of a waste: during
1195 ;; conversion we cannot use the untrusted ASSERT-CALL-TYPE, etc.
1200 ;; Don't validate multiple times against the same leaf --
1201 ;; it doesn't add any information, but may generate the same warning
1202 ;; multiple times.
1206 :result-test nil
1208 #'compiler-warn
1211 same-file-p)
1217 :result-test nil
1227 ;;; This is called by IR1-OPTIMIZE when the function for a call has
1228 ;;; changed. If the call is local, we try to LET-convert it, and
1229 ;;; derive the result type. If it is a :FULL call, we validate it
1230 ;;; against the type, which recognizes known calls, does inline
1231 ;;; expansion, etc. If a call to a predicate in a non-conditional
1232 ;;; position or to a function with a source transform, then we
1233 ;;; reconvert the form to give IR1 another chance.
1240 (:local
1245 (:full
1253 call))
1261 predicate)
1275 \f
1276 ;;;; known function optimization
1278 ;;; Add a failed optimization note to FAILED-OPTIMZATIONS for NODE,
1279 ;;; FUN and ARGS. If there is already a note for NODE and TRANSFORM,
1280 ;;; replace it, otherwise add a new one.
1291 ;;; Attempt to transform NODE using TRANSFORM-FUNCTION, subject to the
1292 ;;; call type constraint TRANSFORM-TYPE. If we are inhibited from
1293 ;;; doing the transform for some reason and FLAME is true, then we
1294 ;;; make a note of the message in FAILED-OPTIMIZATIONS for IR1
1295 ;;; finalize to pick up. We return true if the transform failed, and
1296 ;;; thus further transformation should be attempted. We return false
1297 ;;; if either the transform succeeded or was aborted.
1317 (:none
1319 nil)
1320 (:aborted
1325 nil)
1326 (:failure
1332 t)
1333 (:delayed
1335 nil))))
1338 type
1342 t)
1344 t))))
1346 ;;; When we don't like an IR1 transform, we throw the severity/reason
1347 ;;; and args.
1348 ;;;
1349 ;;; GIVE-UP-IR1-TRANSFORM is used to throw out of an IR1 transform,
1350 ;;; aborting this attempt to transform the call, but admitting the
1351 ;;; possibility that this or some other transform will later succeed.
1352 ;;; If arguments are supplied, they are format arguments for an
1353 ;;; efficiency note.
1354 ;;;
1355 ;;; ABORT-IR1-TRANSFORM is used to throw out of an IR1 transform and
1356 ;;; force a normal call to the function at run time. No further
1357 ;;; optimizations will be attempted.
1358 ;;;
1359 ;;; DELAY-IR1-TRANSFORM is used to throw out of an IR1 transform, and
1360 ;;; delay the transform on the node until later. REASONS specifies
1361 ;;; when the transform will be later retried. The :OPTIMIZE reason
1362 ;;; causes the transform to be delayed until after the current IR1
1363 ;;; optimization pass. The :CONSTRAINT reason causes the transform to
1364 ;;; be delayed until after constraint propagation.
1365 ;;;
1366 ;;; FIXME: Now (0.6.11.44) that there are 4 variants of this (GIVE-UP,
1367 ;;; ABORT, DELAY/:OPTIMIZE, DELAY/:CONSTRAINT) and we're starting to
1368 ;;; do CASE operations on the various REASON values, it might be a
1369 ;;; good idea to go OO, representing the reasons by objects, using
1370 ;;; CLOS methods on the objects instead of CASE, and (possibly) using
1371 ;;; SIGNAL instead of THROW.
1388 ;;; Poor man's catching and resignalling
1389 ;;; Implicit %GIVE-UP macrolet will resignal the give-up "condition"
1399 (:delayed
1407 ;;; Clear any delayed transform with no reasons - these should have
1408 ;;; been tried in the last pass. Then remove the reason from the
1409 ;;; delayed transform reasons, and if any become empty then set
1410 ;;; reoptimize flags for the node. Return true if any transforms are
1411 ;;; to be retried.
1427 reoptimize))
1429 ;;; Take the lambda-expression RES, IR1 convert it in the proper
1430 ;;; environment, and then install it as the function for the call
1431 ;;; NODE. We do local call analysis so that the new function is
1432 ;;; integrated into the control flow.
1433 ;;;
1434 ;;; We require the original function source name in order to generate
1435 ;;; a meaningful debug name for the lambda we set up. (It'd be
1436 ;;; possible to do this starting from debug names as well as source
1437 ;;; names, but as of sbcl-0.7.1.5, there was no need for this
1438 ;;; generality, since source names are always known to our callers.)
1444 ;; The internal variables of a transform are not going to be
1445 ;; interesting to the debugger, so there's no sense in
1446 ;; suppressing the substitution of variables with only one use
1447 ;; (the extra variables can slow down constraint propagation).
1448 ;;
1449 ;; This needs to be done before the WITH-IR1-ENVIRONMENT-FROM-NODE,
1450 ;; so that it will bind *LEXENV* to the right environment.
1463 res
1472 ;;; Replace a call to a foldable function of constant arguments with
1473 ;;; the result of evaluating the form. If there is an error during the
1474 ;;; evaluation, we give a warning and leave the call alone, making the
1475 ;;; call a :ERROR call.
1476 ;;;
1477 ;;; If there is more than one value, then we transform the call into a
1478 ;;; VALUES form.
1484 args
1485 call
1486 ;; Note: CMU CL had COMPILER-WARN here, and that
1487 ;; seems more natural, but it's probably not.
1488 ;;
1489 ;; It's especially not while bug 173 exists:
1490 ;; Expressions like
1491 ;; (COND (END
1492 ;; (UNLESS (OR UNSAFE? (<= END SIZE)))
1493 ;; ...))
1494 ;; can cause constant-folding TYPE-ERRORs (in
1495 ;; #'<=) when END can be proved to be NIL, even
1496 ;; though the code is perfectly legal and safe
1497 ;; because a NIL value of END means that the
1498 ;; #'<= will never be executed.
1499 ;;
1500 ;; Moreover, even without bug 173,
1501 ;; quite-possibly-valid code like
1502 ;; (COND ((NONINLINED-PREDICATE END)
1503 ;; (UNLESS (<= END SIZE))
1504 ;; ...))
1505 ;; (where NONINLINED-PREDICATE is something the
1506 ;; compiler can't do at compile time, but which
1507 ;; turns out to make the #'<= expression
1508 ;; unreachable when END=NIL) could cause errors
1509 ;; when the compiler tries to constant-fold (<=
1510 ;; END SIZE).
1511 ;;
1512 ;; So, with or without bug 173, it'd be
1513 ;; unnecessarily evil to do a full
1514 ;; COMPILER-WARNING (and thus return FAILURE-P=T
1515 ;; from COMPILE-FILE) for legal code, so we we
1516 ;; use a wimpier COMPILE-STYLE-WARNING instead.
1518 ;; On the other hand, for code we control, we
1519 ;; should be able to work around any bug
1520 ;; 173-related problems, and in particular we
1521 ;; want to be alerted to calls to our own
1522 ;; functions which aren't being folded away; a
1523 ;; COMPILER-WARNING is butch enough to stop the
1524 ;; SBCL build itself in its tracks.
1544 call
1548 fun-name))))))
1550 \f
1551 ;;;; local call optimization
1553 ;;; Propagate TYPE to LEAF and its REFS, marking things changed.
1554 ;;;
1555 ;;; If the leaf type is a function type, then just leave it alone, since TYPE
1556 ;;; is never going to be more specific than that (and TYPE-INTERSECTION would
1557 ;;; choke.)
1558 ;;;
1559 ;;; Also, if the type is one requiring special care don't touch it if the leaf
1560 ;;; has multiple references -- otherwise LVAR-CONSERVATIVE-TYPE is screwed.
1575 ;; KLUDGE: LET var substitution
1581 ;;; Iteration variable: exactly one SETQ of the form:
1582 ;;;
1583 ;;; (let ((var initial))
1584 ;;; ...
1585 ;;; (setq var (+ var step))
1586 ;;; ...)
1612 ;; Detect cases like (LOOP FOR 1.0 to 5.0 ...), where
1613 ;; the initial and the step are of different types,
1614 ;; and the step is less contagious.
1617 step-type))))
1656 :low low
1657 :high high
1660 "check for iteration variable reoptimization"
1670 ;;; Figure out the type of a LET variable that has sets. We compute
1671 ;;; the union of the INITIAL-TYPE and the types of all the set
1672 ;;; values and to a PROPAGATE-TO-REFS with this type.
1692 ;;; If a LET variable, find the initial value's type and do
1693 ;;; PROPAGATE-FROM-SETS. We also derive the VALUE's type as the node's
1694 ;;; type.
1710 ;;; Return true if the value of REF will always be the same (and is
1711 ;;; thus legal to substitute.)
1723 (:global-function
1730 ;;; If we have a non-set LET var with a single use, then (if possible)
1731 ;;; replace the variable reference's LVAR with the arg lvar.
1732 ;;;
1733 ;;; We change the REF to be a reference to NIL with unused value, and
1734 ;;; let it be flushed as dead code. A side effect of this substitution
1735 ;;; is to delete the variable.
1743 ;; Think about (LET ((A ...)) (IF ... A ...)): two
1744 ;; LVAR-USEs should not be met on one path. Another problem
1745 ;; is with dynamic-extent.
1748 ;; If the destinatation is dynamic extent, don't substitute unless
1749 ;; the source is as well.
1754 ;; we should not change lifetime of unknown values lvars
1761 ;; CASTs can disappear, don't substitute if
1762 ;; DEST-LVAR has other uses (this will be
1763 ;; insufficient if we have a CAST-CAST chain, but
1764 ;; works well for a single CAST)
1772 ;; While CRETURN and EXIT nodes may be known-values,
1773 ;; they have their own complications, such as
1774 ;; substitution into CRETURN may create new tail calls.
1775 nil)
1778 t))
1784 ;; Really it is (EQ (LVAR-USES LVAR) REF):
1785 t)
1790 ;; KLUDGE: it should be (TYPE-CHECK 0)
1794 ;; FIXME
1795 t)
1803 t)))
1805 ;;; Delete a LET, removing the call and bind nodes, and warning about
1806 ;;; any unreferenced variables. Note that FLUSH-DEAD-CODE will come
1807 ;;; along right away and delete the REF and then the lambda, since we
1808 ;;; flush the FUN lvar.
1823 ;;; This function is called when one of the arguments to a LET
1824 ;;; changes. We look at each changed argument. If the corresponding
1825 ;;; variable is set, then we call PROPAGATE-FROM-SETS. Otherwise, we
1826 ;;; consider substituting for the variable, and also propagate
1827 ;;; derived-type information for the arg to all the VAR's refs.
1828 ;;;
1829 ;;; Substitution is inhibited when the arg leaf's derived type isn't a
1830 ;;; subtype of the argument's leaf type. This prevents type checking
1831 ;;; from being defeated, and also ensures that the best representation
1832 ;;; for the variable can be used.
1833 ;;;
1834 ;;; Substitution of individual references is inhibited if the
1835 ;;; reference is in a different component from the home. This can only
1836 ;;; happen with closures over top level lambda vars. In such cases,
1837 ;;; the references may have already been compiled, and thus can't be
1838 ;;; retroactively modified.
1839 ;;;
1840 ;;; If all of the variables are deleted (have no references) when we
1841 ;;; are done, then we delete the LET.
1842 ;;;
1843 ;;; Note that we are responsible for clearing the LVAR-REOPTIMIZE
1844 ;;; flags.
1859 ;; (NODE-DERIVED-TYPE USE) would
1860 ;; be better -- APD, 2003-05-15
1867 t)
1870 nil)))
1871 leaf var)))
1872 t)))))
1884 ;;; This function is called when one of the args to a non-LET local
1885 ;;; call changes. For each changed argument corresponding to an unset
1886 ;;; variable, we compute the union of the types across all calls and
1887 ;;; propagate this type information to the var's refs.
1888 ;;;
1889 ;;; If the function has an entry-fun, then we don't do anything: since
1890 ;;; it has a XEP we would not discover anything.
1891 ;;;
1892 ;;; If the function is an optional-entry-point, we will just make sure
1893 ;;; &REST lists are known to be lists. Doing the regular rigamarole
1894 ;;; can erronously propagate too strict types into refs: see
1895 ;;; BUG-655203-REGRESSION in tests/compiler.pure.lisp.
1896 ;;;
1897 ;;; We can clear the LVAR-REOPTIMIZE flags for arguments in all calls
1898 ;;; corresponding to changed arguments in CALL, since the only use in
1899 ;;; IR1 optimization of the REOPTIMIZE flag for local call args is
1900 ;;; right here.
1905 ;; We can still make sure &REST is known to be a list.
1910 ;; The normal case.
1918 vars))
1934 union)))))
1937 and type in union
1941 \f
1942 ;;;; multiple values optimization
1944 ;;; Do stuff to notice a change to a MV combination node. There are
1945 ;;; two main branches here:
1946 ;;; -- If the call is local, then it is already a MV let, or should
1947 ;;; become one. Note that although all :LOCAL MV calls must eventually
1948 ;;; be converted to :MV-LETs, there can be a window when the call
1949 ;;; is local, but has not been LET converted yet. This is because
1950 ;;; the entry-point lambdas may have stray references (in other
1951 ;;; entry points) that have not been deleted yet.
1952 ;;; -- The call is full. This case is somewhat similar to the non-MV
1953 ;;; combination optimization: we propagate return type information and
1954 ;;; notice non-returning calls. We also have an optimization
1955 ;;; which tries to convert MV-CALLs into MV-binds.
1961 (:local
1969 (:full
1991 ;;; Propagate derived type info from the values lvar to the vars.
1998 n-vars)))
2000 and type in types
2007 ;;; If possible, convert a general MV call to an MV-BIND. We can do
2008 ;;; this if:
2009 ;;; -- The call has only one argument, and
2010 ;;; -- The function has a known fixed number of arguments, or
2011 ;;; -- The argument yields a known fixed number of values.
2012 ;;;
2013 ;;; What we do is change the function in the MV-CALL to be a lambda
2014 ;;; that "looks like an MV bind", which allows
2015 ;;; IR1-OPTIMIZE-MV-COMBINATION to notice that this call can be
2016 ;;; converted (the next time around.) This new lambda just calls the
2017 ;;; actual function with the MV-BIND variables as arguments. Note that
2018 ;;; this new MV bind is not let-converted immediately, as there are
2019 ;;; going to be stray references from the entry-point functions until
2020 ;;; they get deleted.
2021 ;;;
2022 ;;; In order to avoid loss of argument count checking, we only do the
2023 ;;; transformation according to a known number of expected argument if
2024 ;;; safety is unimportant. We can always convert if we know the number
2025 ;;; of actual values, since the normal call that we build will still
2026 ;;; do any appropriate argument count checking.
2027 ;;;
2028 ;;; We only attempt the transformation if the called function is a
2029 ;;; constant reference. This allows us to just splice the leaf into
2030 ;;; the new function, instead of trying to somehow bind the function
2031 ;;; expression. The leaf must be constant because we are evaluating it
2032 ;;; again in a different place. This also has the effect of squelching
2033 ;;; multiple warnings when there is an argument count error.
2055 "MULTIPLE-VALUE-CALL with ~R values when the function expects ~
2056 at least ~R."
2057 total-nvals min)
2062 "MULTIPLE-VALUE-CALL with ~R values when the function expects ~
2063 at most ~R."
2064 total-nvals max)
2071 min)
2090 ;;; If we see:
2091 ;;; (multiple-value-bind
2092 ;;; (x y)
2093 ;;; (values xx yy)
2094 ;;; ...)
2095 ;;; Convert to:
2096 ;;; (let ((x xx)
2097 ;;; (y yy))
2098 ;;; ...)
2099 ;;;
2100 ;;; What we actually do is convert the VALUES combination into a
2101 ;;; normal LET combination calling the original :MV-LET lambda. If
2102 ;;; there are extra args to VALUES, discard the corresponding
2103 ;;; lvars. If there are insufficient args, insert references to NIL.
2126 for prev = node-prev then ctran
2132 use ctran))
2146 ;; Propagate derived types from the VALUES call to its args:
2147 ;; transforms can leave the VALUES call with a better type
2148 ;; than its args have, so make sure not to throw that away.
2154 ;; Propagate declared types of MV-BIND variables.
2157 t)))
2159 ;;; If we see:
2160 ;;; (values-list (list x y z))
2161 ;;;
2162 ;;; Convert to:
2163 ;;; (values x y z)
2164 ;;;
2165 ;;; In implementation, this is somewhat similar to
2166 ;;; CONVERT-MV-BIND-TO-LET. We grab the args of LIST and make them
2167 ;;; args of the VALUES-LIST call, flushing the old argument lvar
2168 ;;; (allowing the LIST to be flushed.)
2169 ;;;
2170 ;;; FIXME: Thus we lose possible type assertions on (LIST ...).
2177 ;; FIXME: VALUES might not satisfy an assertion on NODE-LVAR.
2189 t)))
2191 ;;; If VALUES appears in a non-MV context, then effectively convert it
2192 ;;; to a PROG1. This allows the computation of the additional values
2193 ;;; to become dead code.
2205 val))
2206 nil))
2208 ;;; TODO:
2209 ;;; - CAST chains;
2224 ;; Vestigial exits are only introduced when eliminating a local
2225 ;; RETURN-FROM. We may delete them only when we can show that
2226 ;; there are no other code paths that use the entry LVAR that
2227 ;; are live from within the block that contained the deleted
2228 ;; EXIT (our predecessor block). The conservative version of
2229 ;; this is that there are no EXITs for any ENTRY introduced
2230 ;; between the LEXENV of the deleted EXIT and the LEXENV of the
2231 ;; target ENTRY.
2246 #+sb-xc-host context
2262 lvar)
2263 ;; Pathwise removing of CAST
2266 next-block)
2294 ;; FIXME: Do it in one step.
2298 value
2304 ;; FIXME: Derived type.
2308 ',detail
2310 ;; KLUDGE: FILTER-LVAR does not work for non-returning
2311 ;; functions, so we declare the return type of
2312 ;; %COMPILE-TIME-TYPE-ERROR to be * and derive the real type
2313 ;; here.
2317 ;; FIXME: Is it necessary?