| blob | e2abea6f7ac320583d23429d4fc4440bd63cd711 |
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 a CONTINUATION whose sole use is a reference to a
22 ;;; constant leaf.
29 ;;; Return the constant value for a continuation whose only use is a
30 ;;; constant node.
35 \f
36 ;;;; interface for obtaining results of type inference
38 ;;; Return a (possibly values) type that describes what we have proven
39 ;;; about the type of Cont without taking any type assertions into
40 ;;; consideration. This is just the union of the NODE-DERIVED-TYPE of
41 ;;; all the uses. Most often people use CONTINUATION-DERIVED-TYPE or
42 ;;; CONTINUATION-TYPE instead of using this function directly.
51 res))
55 (:inside-block
58 ;;; Our best guess for the type of this continuation's value. Note
59 ;;; that this may be VALUES or FUNCTION type, which cannot be passed
60 ;;; as an argument to the normal type operations. See
61 ;;; CONTINUATION-TYPE. This may be called on deleted continuations,
62 ;;; always returning *.
63 ;;;
64 ;;; What we do is call CONTINUATION-PROVEN-TYPE and check whether the
65 ;;; result is a subtype of the assertion. If so, return the proven
66 ;;; type and set TYPE-CHECK to nil. Otherwise, return the intersection
67 ;;; of the asserted and proven types, and set TYPE-CHECK T. If
68 ;;; TYPE-CHECK already has a non-null value, then preserve it. Only in
69 ;;; the somewhat unusual circumstance of a newly discovered assertion
70 ;;; will we change TYPE-CHECK from NIL to T.
71 ;;;
72 ;;; The result value is cached in the CONTINUATION-%DERIVED-TYPE slot.
73 ;;; If the slot is true, just return that value, otherwise recompute
74 ;;; and stash the value there.
89 ;; It's physically impossible for a runtime type check to
90 ;; distinguish between the various subtypes of FUNCTION, so
91 ;; it'd be pointless to do more type checks here.
94 ;; FIXME: This should depend on optimization
95 ;; policy. This is for SPEED > SAFETY:
97 ;; and this is for SAFETY >= SPEED:
108 ;;; Call CONTINUATION-DERIVED-TYPE to make sure the slot is up to
109 ;;; date, then return it.
116 ;;; Return the derived type for CONT's first value. This is guaranteed
117 ;;; not to be a VALUES or FUNCTION type.
122 ;;; If CONT is an argument of a function, return a type which the
123 ;;; function checks CONT for.
132 ;; TODO: MV-COMBINATION
138 ;; FUN-TYPE might be (AND FUNCTION (SATISFIES ...)).
150 ;; TODO: &KEY
152 for arg of-type continuation in args
153 and type of-type ctype in arg-types
156 type)))
158 \f
159 ;;;; interface routines used by optimizers
161 ;;; This function is called by optimizers to indicate that something
162 ;;; interesting has happened to the value of CONT. Optimizers must
163 ;;; make sure that they don't call for reoptimization when nothing has
164 ;;; happened, since optimization will fail to terminate.
165 ;;;
166 ;;; We clear any cached type for the continuation and set the
167 ;;; reoptimize flags on everything in sight, unless the continuation
168 ;;; is deleted (in which case we do nothing.)
169 ;;;
170 ;;; Since this can get called during IR1 conversion, we have to be
171 ;;; careful not to fly into space when the DEST's PREV is missing.
192 ;;; Annotate NODE to indicate that its result has been proven to be
193 ;;; TYPEP to RTYPE. After IR1 conversion has happened, this is the
194 ;;; only correct way to supply information discovered about a node's
195 ;;; type. If you screw with the NODE-DERIVED-TYPE directly, then
196 ;;; information may be lost and reoptimization may not happen.
197 ;;;
198 ;;; What we do is intersect RTYPE with NODE's DERIVED-TYPE. If the
199 ;;; intersection is different from the old type, then we do a
200 ;;; REOPTIMIZE-CONTINUATION on the NODE-CONT.
212 "New inferred type ~S conflicts with old type:~
213 ~% ~S~%*** possible internal error? Please report this."
233 type-check type-asserted)
234 t))
238 ;;; This is similar to DERIVE-NODE-TYPE, but asserts that it is an
239 ;;; error for CONT's value not to be TYPEP to TYPE. If we improve the
240 ;;; assertion, we set TYPE-CHECK and TYPE-ASSERTED to guarantee that
241 ;;; the new assertion will be checked.
248 ;;; Assert that CALL is to a function of the specified TYPE. It is
249 ;;; assumed that the call is legal and has only constants in the
250 ;;; keyword positions.
277 policy))))))
279 \f
280 ;;;; IR1-OPTIMIZE
282 ;;; Do one forward pass over COMPONENT, deleting unreachable blocks
283 ;;; and doing IR1 optimizations. We can ignore all blocks that don't
284 ;;; have the REOPTIMIZE flag set. If COMPONENT-REOPTIMIZE is true when
285 ;;; we are done, then another iteration would be beneficial.
291 ;; We delete blocks when there is either no predecessor or the
292 ;; block is in a lambda that has been deleted. These blocks
293 ;; would eventually be deleted by DFO recomputation, but doing
294 ;; it here immediately makes the effect available to IR1
295 ;; optimization.
300 ;; Preserve the BLOCK-SUCC invariant that almost every block has
301 ;; one successor (and a block with DELETE-P set is an acceptable
302 ;; exception).
335 ;;; Loop over the nodes in BLOCK, acting on (and clearing) REOPTIMIZE
336 ;;; flags.
337 ;;;
338 ;;; Note that although they are cleared here, REOPTIMIZE flags might
339 ;;; still be set upon return from this function, meaning that further
340 ;;; optimization is wanted (as a consequence of optimizations we did).
343 ;; We clear the node and block REOPTIMIZE flags before doing the
344 ;; optimization, not after. This ensures that the node or block will
345 ;; be reoptimized if necessary.
349 ;; As above, we clear the node REOPTIMIZE flag before optimizing.
354 ;; With a COMBINATION, we call PROPAGATE-FUN-CHANGE whenever
355 ;; the function changes, and call IR1-OPTIMIZE-COMBINATION if
356 ;; any argument changes.
361 ;; KLUDGE: We leave the NODE-OPTIMIZE flag set going into
362 ;; IR1-OPTIMIZE-RETURN, since IR1-OPTIMIZE-RETURN wants to
363 ;; clear the flag itself. -- WHN 2002-02-02, quoting original
364 ;; CMU CL comments
370 ;; With an EXIT, we derive the node's type from the VALUE's
371 ;; type. We don't propagate CONT's assertion to the VALUE,
372 ;; since if we did, this would move the checking of CONT's
373 ;; assertion to the exit. This wouldn't work with CATCH and
374 ;; UWP, where the EXIT node is just a placeholder for the
375 ;; actual unknown exit.
384 ;;; Try to join with a successor block. If we succeed, we return true,
385 ;;; otherwise false.
395 ;; The successor has more than one predecessor.
397 ;; The last node's CONT is also used somewhere else.
399 ;; The successor is the current block (infinite loop).
401 ;; The next block has a different cleanup, and thus
402 ;; we may want to insert cleanup code between the
403 ;; two blocks at some point.
406 ;; The next block has a different home lambda, and
407 ;; thus the control transfer is a non-local exit.
410 nil)
411 ;; Joining is easy when the successor's START
412 ;; continuation is the same from our LAST's CONT.
415 t)
416 ;; If they differ, then we can still join when the last
417 ;; continuation has no next and the next continuation
418 ;; has no uses.
421 ;; In this case, we replace the next
422 ;; continuation with the last before joining the blocks.
424 ;; If NEXT-CONT does have a dest, it must be
425 ;; unreachable, since there are no USES.
426 ;; DELETE-CONTINUATION will mark the dest block as
427 ;; DELETE-P [and also this block, unless it is no
428 ;; longer backward reachable from the dest block.]
434 t)
436 nil))))))
438 ;;; Join together two blocks which have the same ending/starting
439 ;;; continuation. The code in BLOCK2 is moved into BLOCK1 and BLOCK2
440 ;;; is deleted from the DFO. We combine the optimize flags for the two
441 ;;; blocks so that any indicated optimization gets done.
474 ;;; Delete any nodes in BLOCK whose value is unused and which have no
475 ;;; side effects. We can delete sets of lexical variables when the set
476 ;;; variable has no references.
490 ;; ### For now, don't delete potentially
491 ;; flushable calls when they have the CALL
492 ;; attribute. Someday we should look at the
493 ;; functional args to determine if they have
494 ;; any side effects.
498 ;; FIXME: when bug 203
499 ;; will be fixed, remove
500 ;; this check
508 :lossage-fun nil
540 \f
541 ;;;; local call return type propagation
543 ;;; This function is called on RETURN nodes that have their REOPTIMIZE
544 ;;; flag set. It iterates over the uses of the RESULT, looking for
545 ;;; interesting stuff to update the TAIL-SET. If a use isn't a local
546 ;;; call, then we union its type together with the types of other such
547 ;;; uses. We assign to the RETURN-RESULT-TYPE the intersection of this
548 ;;; type with the RESULT's asserted type. We can make this
549 ;;; intersection now (potentially before type checking) because this
550 ;;; assertion on the result will eventually be checked (if
551 ;;; appropriate.)
552 ;;;
553 ;;; We call MAYBE-CONVERT-TAIL-LOCAL-CALL on each local non-MV
554 ;;; combination, which may change the succesor of the call to be the
555 ;;; called function, and if so, checks if the call can become an
556 ;;; assignment. If we convert to an assignment, we abort, since the
557 ;;; RETURN has been deleted.
578 ;;; Do stuff to realize that something has changed about the value
579 ;;; delivered to a return node. Since we consider the return values of
580 ;;; all functions in the tail set to be equivalent, this amounts to
581 ;;; bringing the entire tail set up to date. We iterate over the
582 ;;; returns for all the functions in the tail set, reanalyzing them
583 ;;; all (not treating Node specially.)
584 ;;;
585 ;;; When we are done, we check whether the new type is different from
586 ;;; the old TAIL-SET-TYPE. If so, we set the type and also reoptimize
587 ;;; all the continuations for references to functions in the tail set.
588 ;;; This will cause IR1-OPTIMIZE-COMBINATION to derive the new type as
589 ;;; the results of the calls.
610 \f
611 ;;;; IF optimization
613 ;;; If the test has multiple uses, replicate the node when possible.
614 ;;; Also check whether the predicate is known to be true or false,
615 ;;; deleting the IF node in favor of the appropriate branch when this
616 ;;; is the case.
648 ;;; Create a new copy of an IF node that tests the value of the node
649 ;;; USE. The test must have >1 use, and must be immediately used by
650 ;;; USE. NODE must be the only node in its block (implying that
651 ;;; block-start = if-test).
652 ;;;
653 ;;; This optimization has an effect semantically similar to the
654 ;;; source-to-source transformation:
655 ;;; (IF (IF A B C) D E) ==>
656 ;;; (IF A (IF B D E) (IF C D E))
657 ;;;
658 ;;; We clobber the NODE-SOURCE-PATH of both the original and the new
659 ;;; node so that dead code deletion notes will definitely not consider
660 ;;; either node to be part of the original source. One node might
661 ;;; become unreachable, resulting in a spurious note.
673 :consequent cblock
697 \f
698 ;;;; exit IR1 optimization
700 ;;; This function attempts to delete an exit node, returning true if
701 ;;; it deletes the block as a consequence:
702 ;;; -- If the exit is degenerate (has no ENTRY), then we don't do
703 ;;; anything, since there is nothing to be done.
704 ;;; -- If the exit node and its ENTRY have the same home lambda then
705 ;;; we know the exit is local, and can delete the exit. We change
706 ;;; uses of the Exit-Value to be uses of the original continuation,
707 ;;; then unlink the node. If the exit is to a TR context, then we
708 ;;; must do MERGE-TAIL-SETS on any local calls which delivered
709 ;;; their value to this exit.
710 ;;; -- If there is no value (as in a GO), then we skip the value
711 ;;; semantics.
712 ;;;
713 ;;; This function is also called by environment analysis, since it
714 ;;; wants all exits to be optimized even if normal optimization was
715 ;;; omitted.
736 \f
737 ;;;; combination IR1 optimization
739 ;;; Report as we try each transform?
740 #!+sb-show
743 ;;; Do IR1 optimizations on a COMBINATION node.
751 (:local
767 ;; KLUDGE: The next test could be made more sensitive,
768 ;; only suppressing constant-folding of functions with
769 ;; CALL attributes when they're actually passed
770 ;; function arguments. -- WHN 19990918
774 ;; Even if the function is foldable in principle,
775 ;; it might be one of our low-level
776 ;; implementation-specific functions. Such
777 ;; functions don't necessarily exist at runtime on
778 ;; a plain vanilla ANSI Common Lisp
779 ;; cross-compilation host, in which case the
780 ;; cross-compiler can't fold it because the
781 ;; cross-compiler doesn't know how to evaluate it.
782 #+sb-xc-host
797 #!+sb-show
803 #!+sb-show
810 ;;; If CALL is to a function that doesn't return (i.e. return type is
811 ;;; NIL), then terminate the block there, and link it to the component
812 ;;; tail. We also change the call's CONT to be a dummy continuation to
813 ;;; prevent the use from confusing things.
814 ;;;
815 ;;; Except when called during IR1 [FIXME: What does this mean? Except
816 ;;; during IR1 conversion? What about IR1 optimization?], we delete
817 ;;; the continuation if it has no other uses. (If it does have other
818 ;;; uses, we reoptimize.)
819 ;;;
820 ;;; Termination on the basis of a continuation type assertion is
821 ;;; inhibited when:
822 ;;; -- The continuation is deleted (hence the assertion is spurious), or
823 ;;; -- We are in IR1 conversion (where THE assertions are subject to
824 ;;; weakening.)
858 t))))
860 ;;; This is called both by IR1 conversion and IR1 optimization when
861 ;;; they have verified the type signature for the call, and are
862 ;;; wondering if something should be done to special-case the call. If
863 ;;; CALL is a call to a global function, then see whether it defined
864 ;;; or known:
865 ;;; -- If a DEFINED-FUN should be inline expanded, then convert
866 ;;; the expansion and change the call to call it. Expansion is
867 ;;; enabled if :INLINE or if SPACE=0. If the FUNCTIONAL slot is
868 ;;; true, we never expand, since this function has already been
869 ;;; converted. Local call analysis will duplicate the definition
870 ;;; if necessary. We claim that the parent form is LABELS for
871 ;;; context declarations, since we don't want it to be considered
872 ;;; a real global function.
873 ;;; -- If it is a known function, mark it as such by setting the KIND.
874 ;;;
875 ;;; We return the leaf referenced (NIL if not a leaf) and the
876 ;;; FUN-INFO assigned.
877 ;;;
878 ;;; FIXME: The IR1-CONVERTING-NOT-OPTIMIZING-P argument is what the
879 ;;; old CMU CL code called IR1-P, without explanation. My (WHN
880 ;;; 2002-01-09) tentative understanding of it is that we can call this
881 ;;; operation either in initial IR1 conversion or in later IR1
882 ;;; optimization, and it tells which is which. But it would be good
883 ;;; for someone who really understands it to check whether this is
884 ;;; really right.
908 ;; called semi-inlining? A more descriptive name would
909 ;; be nice. -- WHN 2002-01-07
913 leaf t
924 nil))
931 ;;; Check whether CALL satisfies TYPE. If so, apply the type to the
932 ;;; call, and do MAYBE-TERMINATE-BLOCK and return the values of
933 ;;; RECOGNIZE-KNOWN-CALL. If an error, set the combination kind and
934 ;;; return NIL, NIL. If the type is just FUNCTION, then skip the
935 ;;; syntax check, arg/result type processing, but still call
936 ;;; RECOGNIZE-KNOWN-CALL, since the call might be to a known lambda,
937 ;;; and that checking is done by local call analysis.
948 ;; KLUDGE: Common Lisp is such a dynamic
949 ;; language that all we can do here in
950 ;; general is issue a STYLE-WARNING. It
951 ;; would be nice to issue a full WARNING
952 ;; in the special case of of type
953 ;; mismatches within a compilation unit
954 ;; (as in section 3.2.2.3 of the spec)
955 ;; but at least as of sbcl-0.6.11, we
956 ;; don't keep track of whether the
957 ;; mismatched data came from the same
958 ;; compilation unit, so we can't do that.
959 ;; -- WHN 2001-02-11
960 ;;
961 ;; FIXME: Actually, I think we could
962 ;; issue a full WARNING if the call
963 ;; violates a DECLAIM FTYPE.
973 ;;; This is called by IR1-OPTIMIZE when the function for a call has
974 ;;; changed. If the call is local, we try to LET-convert it, and
975 ;;; derive the result type. If it is a :FULL call, we validate it
976 ;;; against the type, which recognizes known calls, does inline
977 ;;; expansion, etc. If a call to a predicate in a non-conditional
978 ;;; position or to a function with a source transform, then we
979 ;;; reconvert the form to give IR1 another chance.
986 (:local
991 (:full
997 call))
1003 predicate)
1006 ;; FIXME: This SYMBOLP is part of a literal
1007 ;; translation of a test in the old CMU CL
1008 ;; source, and it's not quite clear what
1009 ;; the old source meant. Did it mean "has a
1010 ;; valid name"? Or did it mean "is an
1011 ;; ordinary function name, not a SETF
1012 ;; function"? Either way, the old CMU CL
1013 ;; code probably didn't deal with SETF
1014 ;; functions correctly, and neither does
1015 ;; this new SBCL code, and that should be fixed.
1025 \f
1026 ;;;; known function optimization
1028 ;;; Add a failed optimization note to FAILED-OPTIMZATIONS for NODE,
1029 ;;; FUN and ARGS. If there is already a note for NODE and TRANSFORM,
1030 ;;; replace it, otherwise add a new one.
1041 ;;; Attempt to transform NODE using TRANSFORM-FUNCTION, subject to the
1042 ;;; call type constraint TRANSFORM-TYPE. If we are inhibited from
1043 ;;; doing the transform for some reason and FLAME is true, then we
1044 ;;; make a note of the message in FAILED-OPTIMIZATIONS for IR1
1045 ;;; finalize to pick up. We return true if the transform failed, and
1046 ;;; thus further transformation should be attempted. We return false
1047 ;;; if either the transform succeeded or was aborted.
1067 (:none
1069 nil)
1070 (:aborted
1075 nil)
1076 (:failure
1082 t)
1083 (:delayed
1085 nil))))
1088 type
1092 t)
1094 t))))
1096 ;;; When we don't like an IR1 transform, we throw the severity/reason
1097 ;;; and args.
1098 ;;;
1099 ;;; GIVE-UP-IR1-TRANSFORM is used to throw out of an IR1 transform,
1100 ;;; aborting this attempt to transform the call, but admitting the
1101 ;;; possibility that this or some other transform will later succeed.
1102 ;;; If arguments are supplied, they are format arguments for an
1103 ;;; efficiency note.
1104 ;;;
1105 ;;; ABORT-IR1-TRANSFORM is used to throw out of an IR1 transform and
1106 ;;; force a normal call to the function at run time. No further
1107 ;;; optimizations will be attempted.
1108 ;;;
1109 ;;; DELAY-IR1-TRANSFORM is used to throw out of an IR1 transform, and
1110 ;;; delay the transform on the node until later. REASONS specifies
1111 ;;; when the transform will be later retried. The :OPTIMIZE reason
1112 ;;; causes the transform to be delayed until after the current IR1
1113 ;;; optimization pass. The :CONSTRAINT reason causes the transform to
1114 ;;; be delayed until after constraint propagation.
1115 ;;;
1116 ;;; FIXME: Now (0.6.11.44) that there are 4 variants of this (GIVE-UP,
1117 ;;; ABORT, DELAY/:OPTIMIZE, DELAY/:CONSTRAINT) and we're starting to
1118 ;;; do CASE operations on the various REASON values, it might be a
1119 ;;; good idea to go OO, representing the reasons by objects, using
1120 ;;; CLOS methods on the objects instead of CASE, and (possibly) using
1121 ;;; SIGNAL instead of THROW.
1138 ;;; Clear any delayed transform with no reasons - these should have
1139 ;;; been tried in the last pass. Then remove the reason from the
1140 ;;; delayed transform reasons, and if any become empty then set
1141 ;;; reoptimize flags for the node. Return true if any transforms are
1142 ;;; to be retried.
1158 reoptimize))
1160 ;;; Take the lambda-expression RES, IR1 convert it in the proper
1161 ;;; environment, and then install it as the function for the call
1162 ;;; NODE. We do local call analysis so that the new function is
1163 ;;; integrated into the control flow.
1164 ;;;
1165 ;;; We require the original function source name in order to generate
1166 ;;; a meaningful debug name for the lambda we set up. (It'd be
1167 ;;; possible to do this starting from debug names as well as source
1168 ;;; names, but as of sbcl-0.7.1.5, there was no need for this
1169 ;;; generality, since source names are always known to our callers.)
1176 res
1179 source-name
1187 ;;; Replace a call to a foldable function of constant arguments with
1188 ;;; the result of evaluating the form. If there is an error during the
1189 ;;; evaluation, we give a warning and leave the call alone, making the
1190 ;;; call a :ERROR call.
1191 ;;;
1192 ;;; If there is more than one value, then we transform the call into a
1193 ;;; VALUES form.
1194 ;;;
1195 ;;; An old commentary also said:
1196 ;;;
1197 ;;; We insert the resulting constant node after the call, stealing
1198 ;;; the call's continuation. We give the call a continuation with no
1199 ;;; DEST, which should cause it and its arguments to go away.
1200 ;;;
1201 ;;; This seems to be more efficient, than the current code. Maybe we
1202 ;;; should really implement it? -- APD, 2002-12-23
1208 args
1209 call
1210 ;; Note: CMU CL had COMPILER-WARN here, and that
1211 ;; seems more natural, but it's probably not.
1212 ;;
1213 ;; It's especially not while bug 173 exists:
1214 ;; Expressions like
1215 ;; (COND (END
1216 ;; (UNLESS (OR UNSAFE? (<= END SIZE)))
1217 ;; ...))
1218 ;; can cause constant-folding TYPE-ERRORs (in
1219 ;; #'<=) when END can be proved to be NIL, even
1220 ;; though the code is perfectly legal and safe
1221 ;; because a NIL value of END means that the
1222 ;; #'<= will never be executed.
1223 ;;
1224 ;; Moreover, even without bug 173,
1225 ;; quite-possibly-valid code like
1226 ;; (COND ((NONINLINED-PREDICATE END)
1227 ;; (UNLESS (<= END SIZE))
1228 ;; ...))
1229 ;; (where NONINLINED-PREDICATE is something the
1230 ;; compiler can't do at compile time, but which
1231 ;; turns out to make the #'<= expression
1232 ;; unreachable when END=NIL) could cause errors
1233 ;; when the compiler tries to constant-fold (<=
1234 ;; END SIZE).
1235 ;;
1236 ;; So, with or without bug 173, it'd be
1237 ;; unnecessarily evil to do a full
1238 ;; COMPILER-WARNING (and thus return FAILURE-P=T
1239 ;; from COMPILE-FILE) for legal code, so we we
1240 ;; use a wimpier COMPILE-STYLE-WARNING instead.
1241 #'compiler-style-warn
1255 ;; FIXME: type checking?
1260 call
1264 fun-name))))))
1266 \f
1267 ;;;; local call optimization
1269 ;;; Propagate TYPE to LEAF and its REFS, marking things changed. If
1270 ;;; the leaf type is a function type, then just leave it alone, since
1271 ;;; TYPE is never going to be more specific than that (and
1272 ;;; TYPE-INTERSECTION would choke.)
1284 ;;; Figure out the type of a LET variable that has sets. We compute
1285 ;;; the union of the initial value TYPE and the types of all the set
1286 ;;; values and to a PROPAGATE-TO-REFS with this type.
1298 ;;; If a LET variable, find the initial value's type and do
1299 ;;; PROPAGATE-FROM-SETS. We also derive the VALUE's type as the node's
1300 ;;; type.
1314 ;;; Return true if the value of REF will always be the same (and is
1315 ;;; thus legal to substitute.)
1332 ;;; If we have a non-set LET var with a single use, then (if possible)
1333 ;;; replace the variable reference's CONT with the arg continuation.
1334 ;;; This is inhibited when:
1335 ;;; -- CONT has other uses, or
1336 ;;; -- CONT receives multiple values, or
1337 ;;; -- the reference is in a different environment from the variable, or
1338 ;;; -- either continuation has a funky TYPE-CHECK annotation.
1339 ;;; -- the continuations have incompatible assertions, so the new asserted type
1340 ;;; would be NIL.
1341 ;;; -- the var's DEST has a different policy than the ARG's (think safety).
1342 ;;;
1343 ;;; We change the REF to be a reference to NIL with unused value, and
1344 ;;; let it be flushed as dead code. A side effect of this substitution
1345 ;;; is to delete the variable.
1354 dest
1361 cont-atype
1373 t)))
1375 ;;; Delete a LET, removing the call and bind nodes, and warning about
1376 ;;; any unreferenced variables. Note that FLUSH-DEAD-CODE will come
1377 ;;; along right away and delete the REF and then the lambda, since we
1378 ;;; flush the FUN continuation.
1390 ;;; This function is called when one of the arguments to a LET
1391 ;;; changes. We look at each changed argument. If the corresponding
1392 ;;; variable is set, then we call PROPAGATE-FROM-SETS. Otherwise, we
1393 ;;; consider substituting for the variable, and also propagate
1394 ;;; derived-type information for the arg to all the VAR's refs.
1395 ;;;
1396 ;;; Substitution is inhibited when the arg leaf's derived type isn't a
1397 ;;; subtype of the argument's asserted type. This prevents type
1398 ;;; checking from being defeated, and also ensures that the best
1399 ;;; representation for the variable can be used.
1400 ;;;
1401 ;;; Substitution of individual references is inhibited if the
1402 ;;; reference is in a different component from the home. This can only
1403 ;;; happen with closures over top level lambda vars. In such cases,
1404 ;;; the references may have already been compiled, and thus can't be
1405 ;;; retroactively modified.
1406 ;;;
1407 ;;; If all of the variables are deleted (have no references) when we
1408 ;;; are done, then we delete the LET.
1409 ;;;
1410 ;;; Note that we are responsible for clearing the
1411 ;;; CONTINUATION-REOPTIMIZE flags.
1432 t)
1435 nil)))
1436 leaf var))
1437 t)))))
1448 ;;; This function is called when one of the args to a non-LET local
1449 ;;; call changes. For each changed argument corresponding to an unset
1450 ;;; variable, we compute the union of the types across all calls and
1451 ;;; propagate this type information to the var's refs.
1452 ;;;
1453 ;;; If the function has an XEP, then we don't do anything, since we
1454 ;;; won't discover anything.
1455 ;;;
1456 ;;; We can clear the Continuation-Reoptimize flags for arguments in
1457 ;;; all calls corresponding to changed arguments in Call, since the
1458 ;;; only use in IR1 optimization of the Reoptimize flag for local call
1459 ;;; args is right here.
1472 vars))
1488 union)))))
1493 vars union)))
1496 \f
1497 ;;;; multiple values optimization
1499 ;;; Do stuff to notice a change to a MV combination node. There are
1500 ;;; two main branches here:
1501 ;;; -- If the call is local, then it is already a MV let, or should
1502 ;;; become one. Note that although all :LOCAL MV calls must eventually
1503 ;;; be converted to :MV-LETs, there can be a window when the call
1504 ;;; is local, but has not been LET converted yet. This is because
1505 ;;; the entry-point lambdas may have stray references (in other
1506 ;;; entry points) that have not been deleted yet.
1507 ;;; -- The call is full. This case is somewhat similar to the non-MV
1508 ;;; combination optimization: we propagate return type information and
1509 ;;; notice non-returning calls. We also have an optimization
1510 ;;; which tries to convert MV-CALLs into MV-binds.
1513 (:local
1522 (:full
1545 ;;; Propagate derived type info from the values continuation to the
1546 ;;; vars.
1558 vars
1565 ;;; If possible, convert a general MV call to an MV-BIND. We can do
1566 ;;; this if:
1567 ;;; -- The call has only one argument, and
1568 ;;; -- The function has a known fixed number of arguments, or
1569 ;;; -- The argument yields a known fixed number of values.
1570 ;;;
1571 ;;; What we do is change the function in the MV-CALL to be a lambda
1572 ;;; that "looks like an MV bind", which allows
1573 ;;; IR1-OPTIMIZE-MV-COMBINATION to notice that this call can be
1574 ;;; converted (the next time around.) This new lambda just calls the
1575 ;;; actual function with the MV-BIND variables as arguments. Note that
1576 ;;; this new MV bind is not let-converted immediately, as there are
1577 ;;; going to be stray references from the entry-point functions until
1578 ;;; they get deleted.
1579 ;;;
1580 ;;; In order to avoid loss of argument count checking, we only do the
1581 ;;; transformation according to a known number of expected argument if
1582 ;;; safety is unimportant. We can always convert if we know the number
1583 ;;; of actual values, since the normal call that we build will still
1584 ;;; do any appropriate argument count checking.
1585 ;;;
1586 ;;; We only attempt the transformation if the called function is a
1587 ;;; constant reference. This allows us to just splice the leaf into
1588 ;;; the new function, instead of trying to somehow bind the function
1589 ;;; expression. The leaf must be constant because we are evaluating it
1590 ;;; again in a different place. This also has the effect of squelching
1591 ;;; multiple warnings when there is an argument count error.
1613 "MULTIPLE-VALUE-CALL with ~R values when the function expects ~
1614 at least ~R."
1615 total-nvals min)
1620 "MULTIPLE-VALUE-CALL with ~R values when the function expects ~
1621 at most ~R."
1622 total-nvals max)
1629 min)
1645 ;;; If we see:
1646 ;;; (multiple-value-bind
1647 ;;; (x y)
1648 ;;; (values xx yy)
1649 ;;; ...)
1650 ;;; Convert to:
1651 ;;; (let ((x xx)
1652 ;;; (y yy))
1653 ;;; ...)
1654 ;;;
1655 ;;; What we actually do is convert the VALUES combination into a
1656 ;;; normal LET combination calling the original :MV-LET lambda. If
1657 ;;; there are extra args to VALUES, discard the corresponding
1658 ;;; continuations. If there are insufficient args, insert references
1659 ;;; to NIL.
1682 and prev = node-prev then cont
1702 t)))
1704 ;;; If we see:
1705 ;;; (values-list (list x y z))
1706 ;;;
1707 ;;; Convert to:
1708 ;;; (values x y z)
1709 ;;;
1710 ;;; In implementation, this is somewhat similar to
1711 ;;; CONVERT-MV-BIND-TO-LET. We grab the args of LIST and make them
1712 ;;; args of the VALUES-LIST call, flushing the old argument
1713 ;;; continuation (allowing the LIST to be flushed.)
1729 t)))
1731 ;;; If VALUES appears in a non-MV context, then effectively convert it
1732 ;;; to a PROG1. This allows the computation of the additional values
1733 ;;; to become dead code.
1743 val))
1744 nil))