| blob | 2ce3000076fb47245e2c7d58daf569ff17f5859b |
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.
29 leaf)
32 ;; LEAF may be a CONSTANT behind a cast that will
33 ;; later turn out to be of the wrong type.
34 ;; And ir1-transforms suffer from this because
35 ;; they expect LVAR-VALUE to be of a restricted type.
38 ;; check for EQL types and singleton numeric types
41 ;;; Return the constant value for an LVAR whose only use is a constant
42 ;;; node.
47 leaf)
54 value))))
55 \f
56 ;;;; interface for obtaining results of type inference
58 ;;; Our best guess for the type of this lvar's value. Note that this
59 ;;; may be VALUES or FUNCTION type, which cannot be passed as an
60 ;;; argument to the normal type operations. See LVAR-TYPE.
61 ;;;
62 ;;; The result value is cached in the LVAR-%DERIVED-TYPE slot. If the
63 ;;; slot is true, just return that value, otherwise recompute and
64 ;;; stash the value there.
74 res))
77 res)))
84 ;;; Return the derived type for LVAR's first value. This is guaranteed
85 ;;; not to be a VALUES or FUNCTION type.
90 ;;; LVAR-CONSERVATIVE-TYPE
91 ;;;
92 ;;; Certain types refer to the contents of an object, which can
93 ;;; change without type derivation noticing: CONS types and ARRAY
94 ;;; types suffer from this:
95 ;;;
96 ;;; (let ((x (the (cons fixnum fixnum) (cons a b))))
97 ;;; (setf (car x) c)
98 ;;; (+ (car x) (cdr x)))
99 ;;;
100 ;;; Python doesn't realize that the SETF CAR can change the type of X -- so we
101 ;;; cannot use LVAR-TYPE which gets the derived results. Worse, still, instead
102 ;;; of (SETF CAR) we might have a call to a user-defined function FOO which
103 ;;; does the same -- so there is no way to use the derived information in
104 ;;; general.
105 ;;;
106 ;;; So, the conservative option is to use the derived type if the leaf has
107 ;;; only a single ref -- in which case there cannot be a prior call that
108 ;;; mutates it. Otherwise we use the declared type or punt to the most general
109 ;;; type we know to be correct for sure.
113 ;; Recompute using NODE-CONSERVATIVE-TYPE instead of derived type if
114 ;; necessary -- picking off some easy cases up front.
116 ;; Can't use CSUBTYPEP!
119 derived-type)
123 derived-type)
129 derived-type)
133 derived-type))))
146 derived-values-type))
147 derived-values-type)))
153 type)
159 ;; ADJUST-ARRAY may change dimensions, but rank stays same.
162 old
164 ;; Complexity cannot change.
166 ;; Element type cannot change.
169 ;; Simple arrays cannot change at all.
170 type))
172 ;; Conservative union type is an union of conservative types.
177 ;; Catch-all.
178 ;;
179 ;; If the type contains some CONS types, the conservative type contains all
180 ;; of them.
183 ;; Similarly for non-simple arrays -- it should be possible to preserve
184 ;; more information here, but really...
188 type)))
192 ;; Excluding T is necessary, because we do want type derivation to
193 ;; be able to narrow it down in case someone (most like a macro-expansion...)
194 ;; actually declares something as having type T.
195 nil)
197 ;; Covered by the next case as well, but this is a quick test.
198 t)
200 t)))
202 ;;; If LVAR is an argument of a function, return a type which the
203 ;;; function checks LVAR for.
212 ;; TODO: MV-COMBINATION
220 ;; FUN-TYPE might be (AND FUNCTION (SATISFIES ...)).
234 dest)))))
236 \f
237 ;;;; interface routines used by optimizers
239 ;;; This function is called by optimizers to indicate that something
240 ;;; interesting has happened to the value of LVAR. Optimizers must
241 ;;; make sure that they don't call for reoptimization when nothing has
242 ;;; happened, since optimization will fail to terminate.
243 ;;;
244 ;;; We clear any cached type for the lvar and set the reoptimize flags
245 ;;; on everything in sight.
255 ;; PREV may be missing.
274 ;;; Annotate NODE to indicate that its result has been proven to be
275 ;;; TYPEP to RTYPE. After IR1 conversion has happened, this is the
276 ;;; only correct way to supply information discovered about a node's
277 ;;; type. If you screw with the NODE-DERIVED-TYPE directly, then
278 ;;; information may be lost and reoptimization may not happen.
279 ;;;
280 ;;; What we do is intersect RTYPE with NODE's DERIVED-TYPE. If the
281 ;;; intersection is different from the old type, then we do a
282 ;;; REOPTIMIZE-LVAR on the NODE-LVAR.
288 initial-type)))
292 ;; Don't use type/=, it will return NIL on unknown types.
293 ;; Instead of checking the second value just negate TYPE=
301 "New inferred type ~S conflicts with old type:~
302 ~% ~S~%*** possible internal error? Please report this."
305 ;; If the new type consists of only one object, replace the
306 ;; node with a constant reference.
317 ;;; This is similar to DERIVE-NODE-TYPE, but asserts that it is an
318 ;;; error for LVAR's value not to be TYPEP to TYPE. We implement it
319 ;;; splitting off DEST a new CAST node; old LVAR will deliver values
320 ;;; to CAST. If we improve the assertion, we set TYPE-CHECK to
321 ;;; guarantee that the new assertion will be checked.
329 context)))
331 t))))
333 \f
334 ;;;; IR1-OPTIMIZE
336 ;;; Do one forward pass over COMPONENT, deleting unreachable blocks
337 ;;; and doing IR1 optimizations. We can ignore all blocks that don't
338 ;;; have the REOPTIMIZE flag set. If COMPONENT-REOPTIMIZE is true when
339 ;;; we are done, then another iteration would be beneficial.
345 for last-block = block
348 ;; We delete blocks when there is either no predecessor or the
349 ;; block is in a lambda that has been deleted. These blocks
350 ;; would eventually be deleted by DFO recomputation, but doing
351 ;; it here immediately makes the effect available to IR1
352 ;; optimization.
358 ;; Preserve the BLOCK-SUCC invariant that almost every block has
359 ;; one successor (and a block with DELETE-P set is an acceptable
360 ;; exception).
395 ;;; Loop over the nodes in BLOCK, acting on (and clearing) REOPTIMIZE
396 ;;; flags.
397 ;;;
398 ;;; Note that although they are cleared here, REOPTIMIZE flags might
399 ;;; still be set upon return from this function, meaning that further
400 ;;; optimization is wanted (as a consequence of optimizations we did).
403 ;; We clear the node and block REOPTIMIZE flags before doing the
404 ;; optimization, not after. This ensures that the node or block will
405 ;; be reoptimized if necessary.
409 ;; As above, we clear the node REOPTIMIZE flag before optimizing.
414 ;; With a COMBINATION, we call PROPAGATE-FUN-CHANGE whenever
415 ;; the function changes, and call IR1-OPTIMIZE-COMBINATION if
416 ;; any argument changes.
421 ;; KLUDGE: We leave the NODE-OPTIMIZE flag set going into
422 ;; IR1-OPTIMIZE-RETURN, since IR1-OPTIMIZE-RETURN wants to
423 ;; clear the flag itself. -- WHN 2002-02-02, quoting original
424 ;; CMU CL comments
430 ;; With an EXIT, we derive the node's type from the VALUE's
431 ;; type.
436 ;; PROPAGATE-FROM-SETS can do a better job if NODE-REOPTIMIZE
437 ;; is accurate till the node actually has been reoptimized.
445 ;;; Try to join with a successor block. If we succeed, we return true,
446 ;;; otherwise false.
453 ;; the successor has more than one predecessor;
455 ;; the successor is the current block (infinite loop);
457 ;; the next block has a different cleanup, and thus
458 ;; we may want to insert cleanup code between the
459 ;; two blocks at some point;
462 ;; the next block has a different home lambda, and
463 ;; thus the control transfer is a non-local exit.
466 ;; Stack analysis phase wants ENTRY to start a block...
472 ;; ... and a DX-allocator to end a block.
474 ;; ... and for there to be no chance of there
475 ;; being two successive USEs of the same
476 ;; multi-valued LVAR in the same block (since
477 ;; we can only insert cleanup code at block
478 ;; boundaries, but need to discard
479 ;; multi-valued LVAR contents before they are
480 ;; overwritten).
483 nil)
486 t)))))
488 ;;; Join together two blocks. The code in BLOCK2 is moved into BLOCK1
489 ;;; and BLOCK2 is deleted from the DFO. We combine the optimize flags
490 ;;; for the two blocks so that any indicated optimization gets done.
522 ;;; Delete any nodes in BLOCK whose value is unused and which have no
523 ;;; side effects. We can delete sets of lexical variables when the set
524 ;;; variable has no references.
533 ;; This must be a preceding node and the current node will
534 ;; overwrite the value, unlink the lvar and the node will
535 ;; get a chance to be deleted on one of the next iterations
571 \f
572 ;;;; local call return type propagation
574 ;;; This function is called on RETURN nodes that have their REOPTIMIZE
575 ;;; flag set. It iterates over the uses of the RESULT, looking for
576 ;;; interesting stuff to update the TAIL-SET. If a use isn't a local
577 ;;; call, then we union its type together with the types of other such
578 ;;; uses. We assign to the RETURN-RESULT-TYPE the intersection of this
579 ;;; type with the RESULT's asserted type. We can make this
580 ;;; intersection now (potentially before type checking) because this
581 ;;; assertion on the result will eventually be checked (if
582 ;;; appropriate.)
583 ;;;
584 ;;; We call MAYBE-CONVERT-TAIL-LOCAL-CALL on each local non-MV
585 ;;; combination, which may change the successor of the call to be the
586 ;;; called function, and if so, checks if the call can become an
587 ;;; assignment. If we convert to an assignment, we abort, since the
588 ;;; RETURN has been deleted.
609 ;; (values-type-intersection
610 ;; (continuation-asserted-type result) ; FIXME -- APD, 2002-01-26
612 ;; )
613 ))
615 nil)
617 ;;; Do stuff to realize that something has changed about the value
618 ;;; delivered to a return node. Since we consider the return values of
619 ;;; all functions in the tail set to be equivalent, this amounts to
620 ;;; bringing the entire tail set up to date. We iterate over the
621 ;;; returns for all the functions in the tail set, reanalyzing them
622 ;;; all (not treating NODE specially.)
623 ;;;
624 ;;; When we are done, we check whether the new type is different from
625 ;;; the old TAIL-SET-TYPE. If so, we set the type and also reoptimize
626 ;;; all the lvars for references to functions in the tail set. This
627 ;;; will cause IR1-OPTIMIZE-COMBINATION to derive the new type as the
628 ;;; results of the calls.
633 :restart
653 \f
654 ;;;; IF optimization
656 ;;; Utility: return T if both argument cblocks are equivalent. For now,
657 ;;; detect only blocks that read the same leaf into the same lvar, and
658 ;;; continue to the same block.
671 ;;; Check whether the predicate is known to be true or false,
672 ;;; deleting the IF node in favor of the appropriate branch when this
673 ;;; is the case.
674 ;;; Similarly, when both branches are equivalent, branch directly to either
675 ;;; of them.
676 ;;; Also, if the test has multiple uses, replicate the node when possible...
677 ;;; in fact, splice in direct jumps to the right branch if possible.
689 alternative)
691 consequent)
694 ;; Even if the references are the same they can have
695 ;; different derived types based on the TEST
696 ;; Don't lose the second type when killing it.
703 alternative))))
711 ;; When we know that we only have a single successor, kill the victim
712 ;; ... unless the victim and the remaining successor are the same.
721 ;; When if/if conversion would leave (if ... (if nil ...)) or
722 ;; (if ... (if not-nil ...)), splice the correct successor right
723 ;; in.
742 ;; only one use left. Just kill the now-useless
743 ;; branch to avoid spurious code deletion notes.
746 node test block
752 ;; Finally, duplicate EQ-nil tests
759 ;; leave the last use as is, instead of replacing
760 ;; the (singly-referenced) CIF node with a duplicate.
763 ;;; Create a new copy of an IF node that tests the value of the node
764 ;;; USE. The test must have >1 use, and must be immediately used by
765 ;;; USE. NODE must be the only node in its block (implying that
766 ;;; block-start = if-test).
767 ;;;
768 ;;; This optimization has an effect semantically similar to the
769 ;;; source-to-source transformation:
770 ;;; (IF (IF A B C) D E) ==>
771 ;;; (IF A (IF B D E) (IF C D E))
772 ;;;
773 ;;; We clobber the NODE-SOURCE-PATH of both the original and the new
774 ;;; node so that dead code deletion notes will definitely not consider
775 ;;; either node to be part of the original source. One node might
776 ;;; become unreachable, resulting in a spurious note.
788 :consequent cblock
810 \f
811 ;;;; exit IR1 optimization
813 ;;; This function attempts to delete an exit node, returning true if
814 ;;; it deletes the block as a consequence:
815 ;;; -- If the exit is degenerate (has no ENTRY), then we don't do
816 ;;; anything, since there is nothing to be done.
817 ;;; -- If the exit node and its ENTRY have the same home lambda then
818 ;;; we know the exit is local, and can delete the exit. We change
819 ;;; uses of the Exit-Value to be uses of the original lvar,
820 ;;; then unlink the node. If the exit is to a TR context, then we
821 ;;; must do MERGE-TAIL-SETS on any local calls which delivered
822 ;;; their value to this exit.
823 ;;; -- If there is no value (as in a GO), then we skip the value
824 ;;; semantics.
825 ;;;
826 ;;; This function is also called by environment analysis, since it
827 ;;; wants all exits to be optimized even if normal optimization was
828 ;;; omitted.
840 \f
841 ;;;; combination IR1 optimization
843 ;;; Report as we try each transform?
844 #!+sb-show
852 "The return value of ~A should not be discarded."
855 ;;; Do IR1 optimizations on a COMBINATION node.
878 (:local
883 (:error
885 (:full
888 ;; This is a known function marked NOTINLINE
891 ;; Check against the DEFINED-TYPE unless TYPE is already good.
901 (:known
917 ;; First give the VM a peek at the call
921 (:direct
922 ;; The VM knows how to handle this.
923 )
924 (:transform
925 ;; The VM mostly knows how to handle this. We need
926 ;; to massage the call slightly, though.
929 ;; Let transforms have a crack at it.
931 #!+sb-show
937 #!+sb-show
951 ;;; If NODE doesn't return (i.e. return type is NIL), then terminate
952 ;;; the block there, and link it to the component tail.
953 ;;;
954 ;;; Except when called during IR1 convertion, we delete the
955 ;;; continuation if it has no other uses. (If it does have other uses,
956 ;;; we reoptimize.)
957 ;;;
958 ;;; Termination on the basis of a continuation type is
959 ;;; inhibited when:
960 ;;; -- The continuation is deleted (hence the assertion is spurious), or
961 ;;; -- We are in IR1 conversion (where THE assertions are subject to
962 ;;; weakening.) FIXME: Now THE assertions are not weakened, but new
963 ;;; uses can(?) be added later. -- APD, 2003-07-17
964 ;;;
965 ;;; Why do we need to consider LVAR type? -- APD, 2003-07-30
976 ;; Even if the combination will never return, don't terminate if this
977 ;; is the tail call of a XEP: doing that would inhibit TCO.
1004 t))))
1006 ;;; This is called both by IR1 conversion and IR1 optimization when
1007 ;;; they have verified the type signature for the call, and are
1008 ;;; wondering if something should be done to special-case the call. If
1009 ;;; CALL is a call to a global function, then see whether it defined
1010 ;;; or known:
1011 ;;; -- If a DEFINED-FUN should be inline expanded, then convert
1012 ;;; the expansion and change the call to call it. Expansion is
1013 ;;; enabled if :INLINE or if SPACE=0. If the FUNCTIONAL slot is
1014 ;;; true, we never expand, since this function has already been
1015 ;;; converted. Local call analysis will duplicate the definition
1016 ;;; if necessary. We claim that the parent form is LABELS for
1017 ;;; context declarations, since we don't want it to be considered
1018 ;;; a real global function.
1019 ;;; -- If it is a known function, mark it as such by setting the KIND.
1020 ;;;
1021 ;;; We return the leaf referenced (NIL if not a leaf) and the
1022 ;;; FUN-INFO assigned.
1046 ;; Inline: if the function has already been converted at another call
1047 ;; site in this component, we point this REF to the functional. If not,
1048 ;; we convert the expansion.
1049 ;;
1050 ;; For :INLINE case local call analysis will copy the expansion later,
1051 ;; but for :MAYBE-INLINE and NIL cases we only get one copy of the
1052 ;; expansion per component.
1053 ;;
1054 ;; FIXME: We also convert in :INLINE & FUNCTIONAL-KIND case below. What
1055 ;; is it for?
1060 ;; Convert.
1063 name
1065 leaf
1066 inlinep
1068 ;; Allow backward references to this function from following
1069 ;; forms. (Reused only if policy matches.)
1074 ;; If we've already converted, change ref to the converted
1075 ;; functional.
1087 ;;; Check whether CALL satisfies TYPE. If so, apply the type to the
1088 ;;; call, and do MAYBE-TERMINATE-BLOCK and return the values of
1089 ;;; RECOGNIZE-KNOWN-CALL. If an error, set the combination kind and
1090 ;;; return NIL, NIL. If the type is just FUNCTION, then skip the
1091 ;;; syntax check, arg/result type processing, but still call
1092 ;;; RECOGNIZE-KNOWN-CALL, since the call might be to a known lambda,
1093 ;;; and that checking is done by local call analysis.
1099 ;; Using the defined-type too early is a bit of a waste: during
1100 ;; conversion we cannot use the untrusted ASSERT-CALL-TYPE, etc.
1105 ;; Don't validate multiple times against the same leaf --
1106 ;; it doesn't add any information, but may generate the same warning
1107 ;; multiple times.
1111 :result-test nil
1113 #'compiler-warn
1116 same-file-p)
1122 :result-test nil
1132 ;;; This is called by IR1-OPTIMIZE when the function for a call has
1133 ;;; changed. If the call is local, we try to LET-convert it, and
1134 ;;; derive the result type. If it is a :FULL call, we validate it
1135 ;;; against the type, which recognizes known calls, does inline
1136 ;;; expansion, etc. If a call to a predicate in a non-conditional
1137 ;;; position or to a function with a source transform, then we
1138 ;;; reconvert the form to give IR1 another chance.
1145 (:local
1150 (:full
1158 call))
1166 predicate)
1179 nil))))))))
1181 \f
1182 ;;;; known function optimization
1184 ;;; Add a failed optimization note to FAILED-OPTIMZATIONS for NODE,
1185 ;;; FUN and ARGS. If there is already a note for NODE and TRANSFORM,
1186 ;;; replace it, otherwise add a new one.
1197 ;;; Attempt to transform NODE using TRANSFORM-FUNCTION, subject to the
1198 ;;; call type constraint TRANSFORM-TYPE. If we are inhibited from
1199 ;;; doing the transform for some reason and FLAME is true, then we
1200 ;;; make a note of the message in FAILED-OPTIMIZATIONS for IR1
1201 ;;; finalize to pick up. We return true if the transform failed, and
1202 ;;; thus further transformation should be attempted. We return false
1203 ;;; if either the transform succeeded or was aborted.
1227 (:none
1229 nil)
1230 (:aborted
1235 nil)
1236 (:failure
1242 t)
1243 (:delayed
1245 nil))))
1248 type
1252 t)
1254 t))))
1256 ;;; When we don't like an IR1 transform, we throw the severity/reason
1257 ;;; and args.
1258 ;;;
1259 ;;; GIVE-UP-IR1-TRANSFORM is used to throw out of an IR1 transform,
1260 ;;; aborting this attempt to transform the call, but admitting the
1261 ;;; possibility that this or some other transform will later succeed.
1262 ;;; If arguments are supplied, they are format arguments for an
1263 ;;; efficiency note.
1264 ;;;
1265 ;;; ABORT-IR1-TRANSFORM is used to throw out of an IR1 transform and
1266 ;;; force a normal call to the function at run time. No further
1267 ;;; optimizations will be attempted.
1268 ;;;
1269 ;;; DELAY-IR1-TRANSFORM is used to throw out of an IR1 transform, and
1270 ;;; delay the transform on the node until later. REASONS specifies
1271 ;;; when the transform will be later retried. The :OPTIMIZE reason
1272 ;;; causes the transform to be delayed until after the current IR1
1273 ;;; optimization pass. The :CONSTRAINT reason causes the transform to
1274 ;;; be delayed until after constraint propagation.
1275 ;;;
1276 ;;; FIXME: Now (0.6.11.44) that there are 4 variants of this (GIVE-UP,
1277 ;;; ABORT, DELAY/:OPTIMIZE, DELAY/:CONSTRAINT) and we're starting to
1278 ;;; do CASE operations on the various REASON values, it might be a
1279 ;;; good idea to go OO, representing the reasons by objects, using
1280 ;;; CLOS methods on the objects instead of CASE, and (possibly) using
1281 ;;; SIGNAL instead of THROW.
1299 ;;; Poor man's catching and resignalling
1300 ;;; Implicit %GIVE-UP macrolet will resignal the give-up "condition"
1310 (:delayed
1318 ;;; Clear any delayed transform with no reasons - these should have
1319 ;;; been tried in the last pass. Then remove the reason from the
1320 ;;; delayed transform reasons, and if any become empty then set
1321 ;;; reoptimize flags for the node. Return true if any transforms are
1322 ;;; to be retried.
1338 reoptimize))
1340 ;;; Take the lambda-expression RES, IR1 convert it in the proper
1341 ;;; environment, and then install it as the function for the call
1342 ;;; NODE. We do local call analysis so that the new function is
1343 ;;; integrated into the control flow.
1344 ;;;
1345 ;;; We require the original function source name in order to generate
1346 ;;; a meaningful debug name for the lambda we set up. (It'd be
1347 ;;; possible to do this starting from debug names as well as source
1348 ;;; names, but as of sbcl-0.7.1.5, there was no need for this
1349 ;;; generality, since source names are always known to our callers.)
1357 :policy
1358 ;; The internal variables of a transform are not going to be
1359 ;; interesting to the debugger, so there's no sense in
1360 ;; suppressing the substitution of variables with only one use
1361 ;; (the extra variables can slow down constraint propagation).
1363 preserve-single-use-debug-variables
1364 0
1371 res
1378 ;; Don't lose the original derived type
1384 ;; Must be done outside of WITH-COMPONENT-LAST-BLOCK
1385 ;; otherwise REMOVE-FROM-DFO might remove that block
1386 ;; but new code still will get attached to it.
1389 ;; This is mainly to call PROPAGATE-LET-ARGS so that the
1390 ;; newly converted code gets to better types sooner.
1398 t)
1407 ;;; Return T if the function is foldable and if it's marked as CALL
1408 ;;; all function arguments are FOLDABLE too.
1414 nil)
1427 combination
1428 info
1431 t)
1435 ;;; Replace a call to a foldable function of constant arguments with
1436 ;;; the result of evaluating the form. If there is an error during the
1437 ;;; evaluation, we give a warning and leave the call alone, making the
1438 ;;; call a :ERROR call.
1439 ;;;
1440 ;;; If there is more than one value, then we transform the call into a
1441 ;;; VALUES form.
1451 lvar))
1455 args)))))
1458 args
1459 call
1460 ;; Note: CMU CL had COMPILER-WARN here, and that
1461 ;; seems more natural, but it's probably not.
1462 ;;
1463 ;; It's especially not while bug 173 exists:
1464 ;; Expressions like
1465 ;; (COND (END
1466 ;; (UNLESS (OR UNSAFE? (<= END SIZE)))
1467 ;; ...))
1468 ;; can cause constant-folding TYPE-ERRORs (in
1469 ;; #'<=) when END can be proved to be NIL, even
1470 ;; though the code is perfectly legal and safe
1471 ;; because a NIL value of END means that the
1472 ;; #'<= will never be executed.
1473 ;;
1474 ;; Moreover, even without bug 173,
1475 ;; quite-possibly-valid code like
1476 ;; (COND ((NONINLINED-PREDICATE END)
1477 ;; (UNLESS (<= END SIZE))
1478 ;; ...))
1479 ;; (where NONINLINED-PREDICATE is something the
1480 ;; compiler can't do at compile time, but which
1481 ;; turns out to make the #'<= expression
1482 ;; unreachable when END=NIL) could cause errors
1483 ;; when the compiler tries to constant-fold (<=
1484 ;; END SIZE).
1485 ;;
1486 ;; So, with or without bug 173, it'd be
1487 ;; unnecessarily evil to do a full
1488 ;; COMPILER-WARNING (and thus return FAILURE-P=T
1489 ;; from COMPILE-FILE) for legal code, so we we
1490 ;; use a wimpier COMPILE-STYLE-WARNING instead.
1492 ;; On the other hand, for code we control, we
1493 ;; should be able to work around any bug
1494 ;; 173-related problems, and in particular we
1495 ;; want to be alerted to calls to our own
1496 ;; functions which aren't being folded away; a
1497 ;; COMPILER-WARNING is butch enough to stop the
1498 ;; SBCL build itself in its tracks.
1518 call
1522 fun-name))))))
1524 \f
1525 ;;;; local call optimization
1527 ;;; Propagate TYPE to LEAF and its REFS, marking things changed.
1528 ;;;
1529 ;;; If the leaf type is a function type, then just leave it alone, since TYPE
1530 ;;; is never going to be more specific than that (and TYPE-INTERSECTION would
1531 ;;; choke.)
1532 ;;;
1533 ;;; Also, if the type is one requiring special care don't touch it if the leaf
1534 ;;; has multiple references -- otherwise LVAR-CONSERVATIVE-TYPE is screwed.
1550 ;; KLUDGE: LET var substitution
1556 ;;; Iteration variable: exactly one SETQ of the form:
1557 ;;;
1558 ;;; (let ((var initial))
1559 ;;; ...
1560 ;;; (setq var (+ var step))
1561 ;;; ...)
1587 ;; Detect cases like (LOOP FOR 1.0 to 5.0 ...), where
1588 ;; the initial and the step are of different types,
1589 ;; and the step is less contagious.
1592 step-type))))
1631 :low low
1632 :high high
1635 "check for iteration variable reoptimization"
1645 ;;; Figure out the type of a LET variable that has sets. We compute
1646 ;;; the union of the INITIAL-TYPE and the types of all the set
1647 ;;; values and to a PROPAGATE-TO-REFS with this type.
1668 ;;; If a LET variable, find the initial value's type and do
1669 ;;; PROPAGATE-FROM-SETS. We also derive the VALUE's type as the node's
1670 ;;; type.
1686 ;;; Return true if the value of REF will always be the same (and is
1687 ;;; thus legal to substitute.)
1699 (:global-function
1706 ;;; If we have a non-set LET var with a single use, then (if possible)
1707 ;;; replace the variable reference's LVAR with the arg lvar.
1708 ;;;
1709 ;;; We change the REF to be a reference to NIL with unused value, and
1710 ;;; let it be flushed as dead code. A side effect of this substitution
1711 ;;; is to delete the variable.
1719 ;; Think about (LET ((A ...)) (IF ... A ...)): two
1720 ;; LVAR-USEs should not be met on one path. Another problem
1721 ;; is with dynamic-extent.
1724 ;; If the destinatation is dynamic extent, don't substitute unless
1725 ;; the source is as well.
1730 ;; we should not change lifetime of unknown values lvars
1737 ;; CASTs can disappear, don't substitute if
1738 ;; DEST-LVAR has other uses (this will be
1739 ;; insufficient if we have a CAST-CAST chain, but
1740 ;; works well for a single CAST)
1748 ;; While CRETURN and EXIT nodes may be known-values,
1749 ;; they have their own complications, such as
1750 ;; substitution into CRETURN may create new tail calls.
1751 nil)
1754 t))
1760 ;; Really it is (EQ (LVAR-USES LVAR) REF):
1761 t)
1766 ;; KLUDGE: it should be (TYPE-CHECK 0)
1770 ;; FIXME
1771 t)
1779 t)))
1781 ;;; Delete a LET, removing the call and bind nodes, and warning about
1782 ;;; any unreferenced variables. Note that FLUSH-DEAD-CODE will come
1783 ;;; along right away and delete the REF and then the lambda, since we
1784 ;;; flush the FUN lvar.
1799 ;;; This function is called when one of the arguments to a LET
1800 ;;; changes. We look at each changed argument. If the corresponding
1801 ;;; variable is set, then we call PROPAGATE-FROM-SETS. Otherwise, we
1802 ;;; consider substituting for the variable, and also propagate
1803 ;;; derived-type information for the arg to all the VAR's refs.
1804 ;;;
1805 ;;; Substitution is inhibited when the arg leaf's derived type isn't a
1806 ;;; subtype of the argument's leaf type. This prevents type checking
1807 ;;; from being defeated, and also ensures that the best representation
1808 ;;; for the variable can be used.
1809 ;;;
1810 ;;; Substitution of individual references is inhibited if the
1811 ;;; reference is in a different component from the home. This can only
1812 ;;; happen with closures over top level lambda vars. In such cases,
1813 ;;; the references may have already been compiled, and thus can't be
1814 ;;; retroactively modified.
1815 ;;;
1816 ;;; If all of the variables are deleted (have no references) when we
1817 ;;; are done, then we delete the LET.
1818 ;;;
1819 ;;; Note that we are responsible for clearing the LVAR-REOPTIMIZE
1820 ;;; flags.
1835 ;; (NODE-DERIVED-TYPE USE) would
1836 ;; be better -- APD, 2003-05-15
1845 t)
1848 nil)))
1849 leaf var)))
1850 t))))))
1857 call
1865 ;;; This function is called when one of the args to a non-LET local
1866 ;;; call changes. For each changed argument corresponding to an unset
1867 ;;; variable, we compute the union of the types across all calls and
1868 ;;; propagate this type information to the var's refs.
1869 ;;;
1870 ;;; If the function has an entry-fun, then we don't do anything: since
1871 ;;; it has a XEP we would not discover anything.
1872 ;;;
1873 ;;; If the function is an optional-entry-point, we will just make sure
1874 ;;; &REST lists are known to be lists. Doing the regular rigamarole
1875 ;;; can erronously propagate too strict types into refs: see
1876 ;;; BUG-655203-REGRESSION in tests/compiler.pure.lisp.
1877 ;;;
1878 ;;; We can clear the LVAR-REOPTIMIZE flags for arguments in all calls
1879 ;;; corresponding to changed arguments in CALL, since the only use in
1880 ;;; IR1 optimization of the REOPTIMIZE flag for local call args is
1881 ;;; right here.
1886 ;; We can still make sure &REST is known to be a list.
1891 ;; The normal case.
1899 vars))
1915 union)))))
1918 and type in union
1922 \f
1923 ;;;; multiple values optimization
1925 ;;; Do stuff to notice a change to a MV combination node. There are
1926 ;;; two main branches here:
1927 ;;; -- If the call is local, then it is already a MV let, or should
1928 ;;; become one. Note that although all :LOCAL MV calls must eventually
1929 ;;; be converted to :MV-LETs, there can be a window when the call
1930 ;;; is local, but has not been LET converted yet. This is because
1931 ;;; the entry-point lambdas may have stray references (in other
1932 ;;; entry points) that have not been deleted yet.
1933 ;;; -- The call is full. This case is somewhat similar to the non-MV
1934 ;;; combination optimization: we propagate return type information and
1935 ;;; notice non-returning calls. We also have an optimization
1936 ;;; which tries to convert MV-CALLs into MV-binds.
1942 (:local
1949 do
1954 (:full
1957 do
1983 else
1984 sum nvals))
1995 "MULTIPLE-VALUE-CALL with at least ~R values when the function expects ~
1996 at most ~R."
1997 min-args max-accepted)
1999 nil)
2014 ;; REFERENCE-LEAF does a better job referencing
2015 ;; DEFINED-FUNs than just using the LVAR.
2029 ;; The total argument count is not known, but all the known
2030 ;; values can already cause a conflict.
2034 ;;; If we see:
2035 ;;; (multiple-value-bind
2036 ;;; (x y)
2037 ;;; (values xx yy)
2038 ;;; ...)
2039 ;;; Convert to:
2040 ;;; (let ((x xx)
2041 ;;; (y yy))
2042 ;;; ...)
2043 ;;;
2044 ;;; What we actually do is convert the VALUES combination into a
2045 ;;; normal LET combination calling the original :MV-LET lambda. If
2046 ;;; there are extra args to VALUES, discard the corresponding
2047 ;;; lvars. If there are insufficient args, insert references to NIL.
2072 for prev = node-prev then ctran
2078 use ctran))
2092 ;; Propagate derived types from the VALUES call to its args:
2093 ;; transforms can leave the VALUES call with a better type
2094 ;; than its args have, so make sure not to throw that away.
2100 ;; Propagate declared types of MV-BIND variables.
2103 t)))
2105 ;;; If we see:
2106 ;;; (values-list (list x y z))
2107 ;;;
2108 ;;; Convert to:
2109 ;;; (values x y z)
2110 ;;;
2111 ;;; In implementation, this is somewhat similar to
2112 ;;; CONVERT-MV-BIND-TO-LET. We grab the args of LIST and make them
2113 ;;; args of the VALUES-LIST call, flushing the old argument lvar
2114 ;;; (allowing the LIST to be flushed.)
2115 ;;;
2116 ;;; FIXME: Thus we lose possible type assertions on (LIST ...).
2123 ;; FIXME: VALUES might not satisfy an assertion on NODE-LVAR.
2135 t)))
2137 ;;; If VALUES appears in a non-MV context, then effectively convert it
2138 ;;; to a PROG1. This allows the computation of the additional values
2139 ;;; to become dead code.
2151 val))
2152 nil))
2154 ;;; TODO:
2155 ;;; - CAST chains;
2172 #+sb-xc-host context
2176 ;; If the destination is a combination-fun that means the function
2177 ;; is called here and not passed somewhere else, there's no longer a
2178 ;; need to check the function type, the arguments to the call will
2179 ;; do the same job.
2203 value)))
2216 t))))))
2225 ;; Run once
2227 t))))
2232 nil)
2243 ;;; Delete or move around casts when possible
2248 nil)
2252 t)
2254 lvar)
2255 ;; Turn (the vector (if x y #()) into
2256 ;; (if x (the vector y) #())
2260 next-block)
2292 ;; No need to transform into an analog of
2293 ;; %COMPILE-TIME-TYPE-ERROR, %CHECK-BOUND will signal at
2294 ;; run-time and %CHECK-BOUND ir2-converter will signal at
2295 ;; compile-time if it survives further stages of ir1
2296 ;; optimization.
2303 value
2309 ;; FIXME: Derived type.
2319 ',detail
2322 ;; KLUDGE: FILTER-LVAR does not work for non-returning
2323 ;; functions, so we declare the return type of
2324 ;; %COMPILE-TIME-TYPE-ERROR to be * and derive the real type
2325 ;; here.
2329 ;; FIXME: Is it necessary?
2350 check)))