| blob | 820fcf4c480d5c9f9302027df4c69d7b208eba0c |
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 ;;; Return the constant value for an LVAR whose only use is a constant
30 ;;; node.
35 \f
36 ;;;; interface for obtaining results of type inference
38 ;;; Our best guess for the type of this lvar's value. Note that this
39 ;;; may be VALUES or FUNCTION type, which cannot be passed as an
40 ;;; argument to the normal type operations. See LVAR-TYPE.
41 ;;;
42 ;;; The result value is cached in the LVAR-%DERIVED-TYPE slot. If the
43 ;;; slot is true, just return that value, otherwise recompute and
44 ;;; stash the value there.
58 res))
64 ;;; Return the derived type for LVAR's first value. This is guaranteed
65 ;;; not to be a VALUES or FUNCTION type.
70 ;;; If LVAR is an argument of a function, return a type which the
71 ;;; function checks LVAR for.
80 ;; TODO: MV-COMBINATION
88 ;; FUN-TYPE might be (AND FUNCTION (SATISFIES ...)).
101 dest)))))
107 \f
108 ;;;; interface routines used by optimizers
110 ;;; This function is called by optimizers to indicate that something
111 ;;; interesting has happened to the value of LVAR. Optimizers must
112 ;;; make sure that they don't call for reoptimization when nothing has
113 ;;; happened, since optimization will fail to terminate.
114 ;;;
115 ;;; We clear any cached type for the lvar and set the reoptimize flags
116 ;;; on everything in sight.
126 ;; PREV may be missing.
145 ;;; Annotate NODE to indicate that its result has been proven to be
146 ;;; TYPEP to RTYPE. After IR1 conversion has happened, this is the
147 ;;; only correct way to supply information discovered about a node's
148 ;;; type. If you screw with the NODE-DERIVED-TYPE directly, then
149 ;;; information may be lost and reoptimization may not happen.
150 ;;;
151 ;;; What we do is intersect RTYPE with NODE's DERIVED-TYPE. If the
152 ;;; intersection is different from the old type, then we do a
153 ;;; REOPTIMIZE-LVAR on the NODE-LVAR.
166 "New inferred type ~S conflicts with old type:~
167 ~% ~S~%*** possible internal error? Please report this."
170 ;; If the new type consists of only one object, replace the
171 ;; node with a constant reference.
182 ;;; This is similar to DERIVE-NODE-TYPE, but asserts that it is an
183 ;;; error for LVAR's value not to be TYPEP to TYPE. We implement it
184 ;;; splitting off DEST a new CAST node; old LVAR will deliver values
185 ;;; to CAST. If we improve the assertion, we set TYPE-CHECK and
186 ;;; TYPE-ASSERTED to guarantee that the new assertion will be checked.
206 type-check type-asserted)
207 t))))))
209 \f
210 ;;;; IR1-OPTIMIZE
212 ;;; Do one forward pass over COMPONENT, deleting unreachable blocks
213 ;;; and doing IR1 optimizations. We can ignore all blocks that don't
214 ;;; have the REOPTIMIZE flag set. If COMPONENT-REOPTIMIZE is true when
215 ;;; we are done, then another iteration would be beneficial.
221 for last-block = block
224 ;; We delete blocks when there is either no predecessor or the
225 ;; block is in a lambda that has been deleted. These blocks
226 ;; would eventually be deleted by DFO recomputation, but doing
227 ;; it here immediately makes the effect available to IR1
228 ;; optimization.
234 ;; Preserve the BLOCK-SUCC invariant that almost every block has
235 ;; one successor (and a block with DELETE-P set is an acceptable
236 ;; exception).
271 ;;; Loop over the nodes in BLOCK, acting on (and clearing) REOPTIMIZE
272 ;;; flags.
273 ;;;
274 ;;; Note that although they are cleared here, REOPTIMIZE flags might
275 ;;; still be set upon return from this function, meaning that further
276 ;;; optimization is wanted (as a consequence of optimizations we did).
279 ;; We clear the node and block REOPTIMIZE flags before doing the
280 ;; optimization, not after. This ensures that the node or block will
281 ;; be reoptimized if necessary.
285 ;; As above, we clear the node REOPTIMIZE flag before optimizing.
290 ;; With a COMBINATION, we call PROPAGATE-FUN-CHANGE whenever
291 ;; the function changes, and call IR1-OPTIMIZE-COMBINATION if
292 ;; any argument changes.
297 ;; KLUDGE: We leave the NODE-OPTIMIZE flag set going into
298 ;; IR1-OPTIMIZE-RETURN, since IR1-OPTIMIZE-RETURN wants to
299 ;; clear the flag itself. -- WHN 2002-02-02, quoting original
300 ;; CMU CL comments
306 ;; With an EXIT, we derive the node's type from the VALUE's
307 ;; type.
318 ;;; Try to join with a successor block. If we succeed, we return true,
319 ;;; otherwise false.
326 ;; the successor has more than one predecessor;
328 ;; the successor is the current block (infinite loop);
330 ;; the next block has a different cleanup, and thus
331 ;; we may want to insert cleanup code between the
332 ;; two blocks at some point;
335 ;; the next block has a different home lambda, and
336 ;; thus the control transfer is a non-local exit.
339 ;; Stack analysis phase wants ENTRY to start a block...
345 ;; ... and a DX-allocator to end a block.
347 ;; FIXME: This is a partial workaround for bug 303.
349 nil)
352 t)))))
354 ;;; Join together two blocks. The code in BLOCK2 is moved into BLOCK1
355 ;;; and BLOCK2 is deleted from the DFO. We combine the optimize flags
356 ;;; for the two blocks so that any indicated optimization gets done.
389 ;;; Delete any nodes in BLOCK whose value is unused and which have no
390 ;;; side effects. We can delete sets of lexical variables when the set
391 ;;; variable has no references.
407 ;; ### For now, don't delete potentially
408 ;; flushable calls when they have the CALL
409 ;; attribute. Someday we should look at the
410 ;; functional args to determine if they have
411 ;; any side effects.
444 \f
445 ;;;; local call return type propagation
447 ;;; This function is called on RETURN nodes that have their REOPTIMIZE
448 ;;; flag set. It iterates over the uses of the RESULT, looking for
449 ;;; interesting stuff to update the TAIL-SET. If a use isn't a local
450 ;;; call, then we union its type together with the types of other such
451 ;;; uses. We assign to the RETURN-RESULT-TYPE the intersection of this
452 ;;; type with the RESULT's asserted type. We can make this
453 ;;; intersection now (potentially before type checking) because this
454 ;;; assertion on the result will eventually be checked (if
455 ;;; appropriate.)
456 ;;;
457 ;;; We call MAYBE-CONVERT-TAIL-LOCAL-CALL on each local non-MV
458 ;;; combination, which may change the succesor of the call to be the
459 ;;; called function, and if so, checks if the call can become an
460 ;;; assignment. If we convert to an assignment, we abort, since the
461 ;;; RETURN has been deleted.
480 ;; (values-type-intersection
481 ;; (continuation-asserted-type result) ; FIXME -- APD, 2002-01-26
483 ;; )
484 ))
486 nil)
488 ;;; Do stuff to realize that something has changed about the value
489 ;;; delivered to a return node. Since we consider the return values of
490 ;;; all functions in the tail set to be equivalent, this amounts to
491 ;;; bringing the entire tail set up to date. We iterate over the
492 ;;; returns for all the functions in the tail set, reanalyzing them
493 ;;; all (not treating NODE specially.)
494 ;;;
495 ;;; When we are done, we check whether the new type is different from
496 ;;; the old TAIL-SET-TYPE. If so, we set the type and also reoptimize
497 ;;; all the lvars for references to functions in the tail set. This
498 ;;; will cause IR1-OPTIMIZE-COMBINATION to derive the new type as the
499 ;;; results of the calls.
503 :restart
523 \f
524 ;;;; IF optimization
526 ;;; If the test has multiple uses, replicate the node when possible.
527 ;;; Also check whether the predicate is known to be true or false,
528 ;;; deleting the IF node in favor of the appropriate branch when this
529 ;;; is the case.
560 ;;; Create a new copy of an IF node that tests the value of the node
561 ;;; USE. The test must have >1 use, and must be immediately used by
562 ;;; USE. NODE must be the only node in its block (implying that
563 ;;; block-start = if-test).
564 ;;;
565 ;;; This optimization has an effect semantically similar to the
566 ;;; source-to-source transformation:
567 ;;; (IF (IF A B C) D E) ==>
568 ;;; (IF A (IF B D E) (IF C D E))
569 ;;;
570 ;;; We clobber the NODE-SOURCE-PATH of both the original and the new
571 ;;; node so that dead code deletion notes will definitely not consider
572 ;;; either node to be part of the original source. One node might
573 ;;; become unreachable, resulting in a spurious note.
585 :consequent cblock
607 \f
608 ;;;; exit IR1 optimization
610 ;;; This function attempts to delete an exit node, returning true if
611 ;;; it deletes the block as a consequence:
612 ;;; -- If the exit is degenerate (has no ENTRY), then we don't do
613 ;;; anything, since there is nothing to be done.
614 ;;; -- If the exit node and its ENTRY have the same home lambda then
615 ;;; we know the exit is local, and can delete the exit. We change
616 ;;; uses of the Exit-Value to be uses of the original lvar,
617 ;;; then unlink the node. If the exit is to a TR context, then we
618 ;;; must do MERGE-TAIL-SETS on any local calls which delivered
619 ;;; their value to this exit.
620 ;;; -- If there is no value (as in a GO), then we skip the value
621 ;;; semantics.
622 ;;;
623 ;;; This function is also called by environment analysis, since it
624 ;;; wants all exits to be optimized even if normal optimization was
625 ;;; omitted.
637 \f
638 ;;;; combination IR1 optimization
640 ;;; Report as we try each transform?
641 #!+sb-show
644 ;;; Do IR1 optimizations on a COMBINATION node.
654 (:local
659 (:error
663 (:full
674 (:known
682 ;; KLUDGE: The next test could be made more sensitive,
683 ;; only suppressing constant-folding of functions with
684 ;; CALL attributes when they're actually passed
685 ;; function arguments. -- WHN 19990918
689 ;; Even if the function is foldable in principle,
690 ;; it might be one of our low-level
691 ;; implementation-specific functions. Such
692 ;; functions don't necessarily exist at runtime on
693 ;; a plain vanilla ANSI Common Lisp
694 ;; cross-compilation host, in which case the
695 ;; cross-compiler can't fold it because the
696 ;; cross-compiler doesn't know how to evaluate it.
697 #+sb-xc-host
702 nil)))
716 #!+sb-show
722 #!+sb-show
729 ;;; If NODE doesn't return (i.e. return type is NIL), then terminate
730 ;;; the block there, and link it to the component tail.
731 ;;;
732 ;;; Except when called during IR1 convertion, we delete the
733 ;;; continuation if it has no other uses. (If it does have other uses,
734 ;;; we reoptimize.)
735 ;;;
736 ;;; Termination on the basis of a continuation type is
737 ;;; inhibited when:
738 ;;; -- The continuation is deleted (hence the assertion is spurious), or
739 ;;; -- We are in IR1 conversion (where THE assertions are subject to
740 ;;; weakening.) FIXME: Now THE assertions are not weakened, but new
741 ;;; uses can(?) be added later. -- APD, 2003-07-17
742 ;;;
743 ;;; Why do we need to consider LVAR type? -- APD, 2003-07-30
779 t))))
781 ;;; This is called both by IR1 conversion and IR1 optimization when
782 ;;; they have verified the type signature for the call, and are
783 ;;; wondering if something should be done to special-case the call. If
784 ;;; CALL is a call to a global function, then see whether it defined
785 ;;; or known:
786 ;;; -- If a DEFINED-FUN should be inline expanded, then convert
787 ;;; the expansion and change the call to call it. Expansion is
788 ;;; enabled if :INLINE or if SPACE=0. If the FUNCTIONAL slot is
789 ;;; true, we never expand, since this function has already been
790 ;;; converted. Local call analysis will duplicate the definition
791 ;;; if necessary. We claim that the parent form is LABELS for
792 ;;; context declarations, since we don't want it to be considered
793 ;;; a real global function.
794 ;;; -- If it is a known function, mark it as such by setting the KIND.
795 ;;;
796 ;;; We return the leaf referenced (NIL if not a leaf) and the
797 ;;; FUN-INFO assigned.
825 ;; called semi-inlining? A more descriptive name would
826 ;; be nice. -- WHN 2002-01-07
831 leaf t
842 nil))
852 ;;; Check whether CALL satisfies TYPE. If so, apply the type to the
853 ;;; call, and do MAYBE-TERMINATE-BLOCK and return the values of
854 ;;; RECOGNIZE-KNOWN-CALL. If an error, set the combination kind and
855 ;;; return NIL, NIL. If the type is just FUNCTION, then skip the
856 ;;; syntax check, arg/result type processing, but still call
857 ;;; RECOGNIZE-KNOWN-CALL, since the call might be to a known lambda,
858 ;;; and that checking is done by local call analysis.
868 :result-test nil
869 ;; KLUDGE: Common Lisp is such a dynamic
870 ;; language that all we can do here in
871 ;; general is issue a STYLE-WARNING. It
872 ;; would be nice to issue a full WARNING
873 ;; in the special case of of type
874 ;; mismatches within a compilation unit
875 ;; (as in section 3.2.2.3 of the spec)
876 ;; but at least as of sbcl-0.6.11, we
877 ;; don't keep track of whether the
878 ;; mismatched data came from the same
879 ;; compilation unit, so we can't do that.
880 ;; -- WHN 2001-02-11
881 ;;
882 ;; FIXME: Actually, I think we could
883 ;; issue a full WARNING if the call
884 ;; violates a DECLAIM FTYPE.
894 ;;; This is called by IR1-OPTIMIZE when the function for a call has
895 ;;; changed. If the call is local, we try to LET-convert it, and
896 ;;; derive the result type. If it is a :FULL call, we validate it
897 ;;; against the type, which recognizes known calls, does inline
898 ;;; expansion, etc. If a call to a predicate in a non-conditional
899 ;;; position or to a function with a source transform, then we
900 ;;; reconvert the form to give IR1 another chance.
907 (:local
912 (:full
918 call))
926 predicate)
940 \f
941 ;;;; known function optimization
943 ;;; Add a failed optimization note to FAILED-OPTIMZATIONS for NODE,
944 ;;; FUN and ARGS. If there is already a note for NODE and TRANSFORM,
945 ;;; replace it, otherwise add a new one.
956 ;;; Attempt to transform NODE using TRANSFORM-FUNCTION, subject to the
957 ;;; call type constraint TRANSFORM-TYPE. If we are inhibited from
958 ;;; doing the transform for some reason and FLAME is true, then we
959 ;;; make a note of the message in FAILED-OPTIMIZATIONS for IR1
960 ;;; finalize to pick up. We return true if the transform failed, and
961 ;;; thus further transformation should be attempted. We return false
962 ;;; if either the transform succeeded or was aborted.
982 (:none
984 nil)
985 (:aborted
990 nil)
991 (:failure
997 t)
998 (:delayed
1000 nil))))
1003 type
1007 t)
1009 t))))
1011 ;;; When we don't like an IR1 transform, we throw the severity/reason
1012 ;;; and args.
1013 ;;;
1014 ;;; GIVE-UP-IR1-TRANSFORM is used to throw out of an IR1 transform,
1015 ;;; aborting this attempt to transform the call, but admitting the
1016 ;;; possibility that this or some other transform will later succeed.
1017 ;;; If arguments are supplied, they are format arguments for an
1018 ;;; efficiency note.
1019 ;;;
1020 ;;; ABORT-IR1-TRANSFORM is used to throw out of an IR1 transform and
1021 ;;; force a normal call to the function at run time. No further
1022 ;;; optimizations will be attempted.
1023 ;;;
1024 ;;; DELAY-IR1-TRANSFORM is used to throw out of an IR1 transform, and
1025 ;;; delay the transform on the node until later. REASONS specifies
1026 ;;; when the transform will be later retried. The :OPTIMIZE reason
1027 ;;; causes the transform to be delayed until after the current IR1
1028 ;;; optimization pass. The :CONSTRAINT reason causes the transform to
1029 ;;; be delayed until after constraint propagation.
1030 ;;;
1031 ;;; FIXME: Now (0.6.11.44) that there are 4 variants of this (GIVE-UP,
1032 ;;; ABORT, DELAY/:OPTIMIZE, DELAY/:CONSTRAINT) and we're starting to
1033 ;;; do CASE operations on the various REASON values, it might be a
1034 ;;; good idea to go OO, representing the reasons by objects, using
1035 ;;; CLOS methods on the objects instead of CASE, and (possibly) using
1036 ;;; SIGNAL instead of THROW.
1053 ;;; Clear any delayed transform with no reasons - these should have
1054 ;;; been tried in the last pass. Then remove the reason from the
1055 ;;; delayed transform reasons, and if any become empty then set
1056 ;;; reoptimize flags for the node. Return true if any transforms are
1057 ;;; to be retried.
1073 reoptimize))
1075 ;;; Take the lambda-expression RES, IR1 convert it in the proper
1076 ;;; environment, and then install it as the function for the call
1077 ;;; NODE. We do local call analysis so that the new function is
1078 ;;; integrated into the control flow.
1079 ;;;
1080 ;;; We require the original function source name in order to generate
1081 ;;; a meaningful debug name for the lambda we set up. (It'd be
1082 ;;; possible to do this starting from debug names as well as source
1083 ;;; names, but as of sbcl-0.7.1.5, there was no need for this
1084 ;;; generality, since source names are always known to our callers.)
1094 res
1096 source-name
1104 ;;; Replace a call to a foldable function of constant arguments with
1105 ;;; the result of evaluating the form. If there is an error during the
1106 ;;; evaluation, we give a warning and leave the call alone, making the
1107 ;;; call a :ERROR call.
1108 ;;;
1109 ;;; If there is more than one value, then we transform the call into a
1110 ;;; VALUES form.
1116 args
1117 call
1118 ;; Note: CMU CL had COMPILER-WARN here, and that
1119 ;; seems more natural, but it's probably not.
1120 ;;
1121 ;; It's especially not while bug 173 exists:
1122 ;; Expressions like
1123 ;; (COND (END
1124 ;; (UNLESS (OR UNSAFE? (<= END SIZE)))
1125 ;; ...))
1126 ;; can cause constant-folding TYPE-ERRORs (in
1127 ;; #'<=) when END can be proved to be NIL, even
1128 ;; though the code is perfectly legal and safe
1129 ;; because a NIL value of END means that the
1130 ;; #'<= will never be executed.
1131 ;;
1132 ;; Moreover, even without bug 173,
1133 ;; quite-possibly-valid code like
1134 ;; (COND ((NONINLINED-PREDICATE END)
1135 ;; (UNLESS (<= END SIZE))
1136 ;; ...))
1137 ;; (where NONINLINED-PREDICATE is something the
1138 ;; compiler can't do at compile time, but which
1139 ;; turns out to make the #'<= expression
1140 ;; unreachable when END=NIL) could cause errors
1141 ;; when the compiler tries to constant-fold (<=
1142 ;; END SIZE).
1143 ;;
1144 ;; So, with or without bug 173, it'd be
1145 ;; unnecessarily evil to do a full
1146 ;; COMPILER-WARNING (and thus return FAILURE-P=T
1147 ;; from COMPILE-FILE) for legal code, so we we
1148 ;; use a wimpier COMPILE-STYLE-WARNING instead.
1149 #'compiler-style-warn
1168 call
1172 fun-name))))))
1174 \f
1175 ;;;; local call optimization
1177 ;;; Propagate TYPE to LEAF and its REFS, marking things changed. If
1178 ;;; the leaf type is a function type, then just leave it alone, since
1179 ;;; TYPE is never going to be more specific than that (and
1180 ;;; TYPE-INTERSECTION would choke.)
1190 ;; KLUDGE: LET var substitution
1196 ;;; Iteration variable: exactly one SETQ of the form:
1197 ;;;
1198 ;;; (let ((var initial))
1199 ;;; ...
1200 ;;; (setq var (+ var step))
1201 ;;; ...)
1239 :low low
1240 :high high
1243 "check for iteration variable reoptimization"
1253 ;;; Figure out the type of a LET variable that has sets. We compute
1254 ;;; the union of the INITIAL-TYPE and the types of all the set
1255 ;;; values and to a PROPAGATE-TO-REFS with this type.
1270 ;;; If a LET variable, find the initial value's type and do
1271 ;;; PROPAGATE-FROM-SETS. We also derive the VALUE's type as the node's
1272 ;;; type.
1288 ;;; Return true if the value of REF will always be the same (and is
1289 ;;; thus legal to substitute.)
1301 (:global-function
1308 ;;; If we have a non-set LET var with a single use, then (if possible)
1309 ;;; replace the variable reference's LVAR with the arg lvar.
1310 ;;;
1311 ;;; We change the REF to be a reference to NIL with unused value, and
1312 ;;; let it be flushed as dead code. A side effect of this substitution
1313 ;;; is to delete the variable.
1320 ;; Think about (LET ((A ...)) (IF ... A ...)): two
1321 ;; LVAR-USEs should not be met on one path. Another problem
1322 ;; is with dynamic-extent.
1325 ;; we should not change lifetime of unknown values lvars
1337 ;; While CRETURN and EXIT nodes may be known-values,
1338 ;; they have their own complications, such as
1339 ;; substitution into CRETURN may create new tail calls.
1340 nil)
1343 t))
1348 ;; Really it is (EQ (LVAR-USES LVAR) REF):
1349 t)
1355 t)))
1357 ;;; Delete a LET, removing the call and bind nodes, and warning about
1358 ;;; any unreferenced variables. Note that FLUSH-DEAD-CODE will come
1359 ;;; along right away and delete the REF and then the lambda, since we
1360 ;;; flush the FUN lvar.
1375 ;;; This function is called when one of the arguments to a LET
1376 ;;; changes. We look at each changed argument. If the corresponding
1377 ;;; variable is set, then we call PROPAGATE-FROM-SETS. Otherwise, we
1378 ;;; consider substituting for the variable, and also propagate
1379 ;;; derived-type information for the arg to all the VAR's refs.
1380 ;;;
1381 ;;; Substitution is inhibited when the arg leaf's derived type isn't a
1382 ;;; subtype of the argument's leaf type. This prevents type checking
1383 ;;; from being defeated, and also ensures that the best representation
1384 ;;; for the variable can be used.
1385 ;;;
1386 ;;; Substitution of individual references is inhibited if the
1387 ;;; reference is in a different component from the home. This can only
1388 ;;; happen with closures over top level lambda vars. In such cases,
1389 ;;; the references may have already been compiled, and thus can't be
1390 ;;; retroactively modified.
1391 ;;;
1392 ;;; If all of the variables are deleted (have no references) when we
1393 ;;; are done, then we delete the LET.
1394 ;;;
1395 ;;; Note that we are responsible for clearing the LVAR-REOPTIMIZE
1396 ;;; flags.
1411 ;; (NODE-DERIVED-TYPE USE) would
1412 ;; be better -- APD, 2003-05-15
1419 t)
1422 nil)))
1423 leaf var)))
1424 t)))))
1435 ;;; This function is called when one of the args to a non-LET local
1436 ;;; call changes. For each changed argument corresponding to an unset
1437 ;;; variable, we compute the union of the types across all calls and
1438 ;;; propagate this type information to the var's refs.
1439 ;;;
1440 ;;; If the function has an XEP, then we don't do anything, since we
1441 ;;; won't discover anything.
1442 ;;;
1443 ;;; We can clear the LVAR-REOPTIMIZE flags for arguments in all calls
1444 ;;; corresponding to changed arguments in CALL, since the only use in
1445 ;;; IR1 optimization of the REOPTIMIZE flag for local call args is
1446 ;;; right here.
1459 vars))
1475 union)))))
1478 and type in union
1482 \f
1483 ;;;; multiple values optimization
1485 ;;; Do stuff to notice a change to a MV combination node. There are
1486 ;;; two main branches here:
1487 ;;; -- If the call is local, then it is already a MV let, or should
1488 ;;; become one. Note that although all :LOCAL MV calls must eventually
1489 ;;; be converted to :MV-LETs, there can be a window when the call
1490 ;;; is local, but has not been LET converted yet. This is because
1491 ;;; the entry-point lambdas may have stray references (in other
1492 ;;; entry points) that have not been deleted yet.
1493 ;;; -- The call is full. This case is somewhat similar to the non-MV
1494 ;;; combination optimization: we propagate return type information and
1495 ;;; notice non-returning calls. We also have an optimization
1496 ;;; which tries to convert MV-CALLs into MV-binds.
1499 (:local
1508 (:full
1531 ;;; Propagate derived type info from the values lvar to the vars.
1538 n-vars)))
1540 and type in types
1547 ;;; If possible, convert a general MV call to an MV-BIND. We can do
1548 ;;; this if:
1549 ;;; -- The call has only one argument, and
1550 ;;; -- The function has a known fixed number of arguments, or
1551 ;;; -- The argument yields a known fixed number of values.
1552 ;;;
1553 ;;; What we do is change the function in the MV-CALL to be a lambda
1554 ;;; that "looks like an MV bind", which allows
1555 ;;; IR1-OPTIMIZE-MV-COMBINATION to notice that this call can be
1556 ;;; converted (the next time around.) This new lambda just calls the
1557 ;;; actual function with the MV-BIND variables as arguments. Note that
1558 ;;; this new MV bind is not let-converted immediately, as there are
1559 ;;; going to be stray references from the entry-point functions until
1560 ;;; they get deleted.
1561 ;;;
1562 ;;; In order to avoid loss of argument count checking, we only do the
1563 ;;; transformation according to a known number of expected argument if
1564 ;;; safety is unimportant. We can always convert if we know the number
1565 ;;; of actual values, since the normal call that we build will still
1566 ;;; do any appropriate argument count checking.
1567 ;;;
1568 ;;; We only attempt the transformation if the called function is a
1569 ;;; constant reference. This allows us to just splice the leaf into
1570 ;;; the new function, instead of trying to somehow bind the function
1571 ;;; expression. The leaf must be constant because we are evaluating it
1572 ;;; again in a different place. This also has the effect of squelching
1573 ;;; multiple warnings when there is an argument count error.
1595 "MULTIPLE-VALUE-CALL with ~R values when the function expects ~
1596 at least ~R."
1597 total-nvals min)
1602 "MULTIPLE-VALUE-CALL with ~R values when the function expects ~
1603 at most ~R."
1604 total-nvals max)
1611 min)
1627 ;;; If we see:
1628 ;;; (multiple-value-bind
1629 ;;; (x y)
1630 ;;; (values xx yy)
1631 ;;; ...)
1632 ;;; Convert to:
1633 ;;; (let ((x xx)
1634 ;;; (y yy))
1635 ;;; ...)
1636 ;;;
1637 ;;; What we actually do is convert the VALUES combination into a
1638 ;;; normal LET combination calling the original :MV-LET lambda. If
1639 ;;; there are extra args to VALUES, discard the corresponding
1640 ;;; lvars. If there are insufficient args, insert references to NIL.
1663 for prev = node-prev then ctran
1669 use ctran))
1685 t)))
1687 ;;; If we see:
1688 ;;; (values-list (list x y z))
1689 ;;;
1690 ;;; Convert to:
1691 ;;; (values x y z)
1692 ;;;
1693 ;;; In implementation, this is somewhat similar to
1694 ;;; CONVERT-MV-BIND-TO-LET. We grab the args of LIST and make them
1695 ;;; args of the VALUES-LIST call, flushing the old argument lvar
1696 ;;; (allowing the LIST to be flushed.)
1697 ;;;
1698 ;;; FIXME: Thus we lose possible type assertions on (LIST ...).
1705 ;; FIXME: VALUES might not satisfy an assertion on NODE-LVAR.
1716 t)))
1718 ;;; If VALUES appears in a non-MV context, then effectively convert it
1719 ;;; to a PROG1. This allows the computation of the additional values
1720 ;;; to become dead code.
1732 val))
1733 nil))
1735 ;;; TODO:
1736 ;;; - CAST chains;
1753 lvar)
1754 ;; Pathwise removing of CAST
1757 next-block)
1785 ;; FIXME: Do it in one step.
1787 value
1793 ;; FIXME: Derived type.
1797 ;; KLUDGE: FILTER-LVAR does not work for non-returning
1798 ;; functions, so we declare the return type of
1799 ;; %COMPILE-TIME-TYPE-ERROR to be * and derive the real type
1800 ;; here.
1804 ;; FIXME: Is it necessary?