| blob | b30b86d3a38fedfda23bd7b4869689b71b51ad8c |
1 ;;;; This file contains the implementation-independent code for Pack
2 ;;;; phase in the compiler. Pack is responsible for assigning TNs to
3 ;;;; storage allocations or "register allocation".
5 ;;;; This software is part of the SBCL system. See the README file for
6 ;;;; more information.
7 ;;;;
8 ;;;; This software is derived from the CMU CL system, which was
9 ;;;; written at Carnegie Mellon University and released into the
10 ;;;; public domain. The software is in the public domain and is
11 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
12 ;;;; files for more information.
16 ;;; for debugging: some parameters controlling which optimizations we
17 ;;; attempt
20 ;;; FIXME: Perhaps SB-FLUID should be renamed to SB-TWEAK and these
21 ;;; should be made conditional on SB-TWEAK.
24 \f
25 ;;;; conflict determination
27 ;;; Return true if the element at the specified offset in SB has a
28 ;;; conflict with TN:
29 ;;; -- If a component-live TN (:COMPONENT kind), then iterate over
30 ;;; all the blocks. If the element at OFFSET is used anywhere in
31 ;;; any of the component's blocks (always-live /= 0), then there
32 ;;; is a conflict.
33 ;;; -- If TN is global (Confs true), then iterate over the blocks TN
34 ;;; is live in (using TN-GLOBAL-CONFLICTS). If the TN is live
35 ;;; everywhere in the block (:LIVE), then there is a conflict
36 ;;; if the element at offset is used anywhere in the block
37 ;;; (Always-Live /= 0). Otherwise, we use the local TN number for
38 ;;; TN in block to find whether TN has a conflict at Offset in
39 ;;; that block.
40 ;;; -- If TN is local, then we just check for a conflict in the block
41 ;;; it is local to.
57 nil)
73 ;;; Return true if TN has a conflict in SC at the specified offset.
81 ;;; Add TN's conflicts into the conflicts for the location at OFFSET
82 ;;; in SC. We iterate over each location in TN, adding to the
83 ;;; conflicts for that location:
84 ;;; -- If TN is a :COMPONENT TN, then iterate over all the blocks,
85 ;;; setting all of the local conflict bits and the always-live bit.
86 ;;; This records a conflict with any TN that has a LTN number in
87 ;;; the block, as well as with :ALWAYS-LIVE and :ENVIRONMENT TNs.
88 ;;; -- If TN is global, then iterate over the blocks TN is live in. In
89 ;;; addition to setting the always-live bit to represent the conflict
90 ;;; with TNs live throughout the block, we also set bits in the
91 ;;; local conflicts. If TN is :ALWAYS-LIVE in the block, we set all
92 ;;; the bits, otherwise we OR in the local conflict bits.
93 ;;; -- If the TN is local, then we just do the block it is local to,
94 ;;; setting always-live and OR'ing in the local conflicts.
127 ;; Calculating ALWAYS-LIVE-COUNT is moderately expensive, and
128 ;; currently the information isn't used unless (> SPEED
129 ;; COMPILE-SPEED).
135 ;; A rought measure of how much a given OFFSET in SB is currently
136 ;; used. Current implementation counts the amount of blocks where the
137 ;; offset has been marked as ALWAYS-LIVE.
145 ;;; Return the total number of IR2-BLOCKs in COMPONENT.
155 ;;; Ensure that the conflicts vectors for each :FINITE SB are large
156 ;;; enough for the number of blocks allocated. Also clear any old
157 ;;; conflicts and reset the current size to the initial size.
210 ;;; Expand the :UNBOUNDED SB backing SC by either the initial size or
211 ;;; the SC element size, whichever is larger. If NEEDED-SIZE is
212 ;;; larger, then use that size.
221 size))
272 \f
273 ;;;; internal errors
275 ;;; Give someone a hard time because there isn't any load function
276 ;;; defined to move from SRC to DEST.
287 from its constant SC ~S"
288 dest-name src-name))
291 alternate SC ~S"
292 dest-name src-name))
295 alternate SC ~S"
296 src-name dest-name))
298 ;; FIXME: "VM definition is inconsistent" shouldn't be a
299 ;; possibility in SBCL.
303 ;;; Called when we failed to pack TN. If RESTRICTED is true, then we
304 ;;; are restricted to pack TN in its SC.
321 a SC for primitive-type ~S."
327 ;;; Return a list of format arguments describing how TN is used in
328 ;;; OP's VOP.
336 temp)
353 temp))))
363 ;;; If load TN packing fails, try to give a helpful error message. We
364 ;;; find a TN in each location that conflicts, and print it.
393 for the ~:R ~:[result~;argument~] to~@
394 the ~S VOP,~@
395 ~:[since all SC elements are in use:~:{~%~@?~}~%~;~
396 ~:*but these SC elements are not in use:~% ~S~%Bug?~*~]~
397 ~:[~;~@
398 Current cost info inconsistent with that in effect at compile ~
399 time. Recompile.~%Compilation order may be incorrect.~]"
401 n arg-p
404 incon))))
406 ;;; This is called when none of the SCs that we can load OP into are
407 ;;; allowed by OP's primitive-type.
417 ~% ~S,~@
418 since the TN's primitive type ~S doesn't allow any of the SCs~@
419 allowed by the operand restriction:~% ~S~
420 ~:[~;~@
421 Current cost info inconsistent with that in effect at compile ~
422 time. Recompile.~%Compilation order may be incorrect.~]"
423 tn pos arg-p
427 incon))))
428 \f
429 ;;;; register saving
431 ;;; Do stuff to note that TN is spilled at VOP for the debugger's benefit.
439 ;;; Make a save TN for TN, pack it, and return it. We copy various
440 ;;; conflict information from the TN so that pack does the right
441 ;;; thing.
455 ;;; Find the load function for moving from SRC to DEST and emit a
456 ;;; MOVE-OPERAND VOP with that function as its info arg.
462 src dest
466 before)
469 ;;; Find the preceding use of the VOP NAME in the emit order, starting
470 ;;; with VOP. We must find the VOP in the same IR1 block.
481 ;;; For TNs that have other than one writer, we save the TN before
482 ;;; each call. If a local call (MOVE-ARGS is :LOCAL-CALL), then we
483 ;;; scan back for the ALLOCATE-FRAME VOP, and emit the save there.
484 ;;; This is necessary because in a self-recursive local call, the
485 ;;; registers holding the current arguments may get trashed by setting
486 ;;; up the call arguments. The ALLOCATE-FRAME VOP marks a place at
487 ;;; which the values are known to be good.
501 vop))
504 ;;; Return a VOP after which is an OK place to save the value of TN.
505 ;;; For correctness, it is only required that this location be after
506 ;;; any possible write and before any possible restore location.
507 ;;;
508 ;;; In practice, we return the unique writer VOP, but give up if the
509 ;;; TN is ever read by a VOP with MOVE-ARGS :LOCAL-CALL. This prevents
510 ;;; us from being confused by non-tail local calls.
511 ;;;
512 ;;; When looking for writes, we have to ignore uses of MOVE-OPERAND,
513 ;;; since they will correspond to restores that we have already done.
534 ;;; Try to save TN at a single location. If we succeed, return T,
535 ;;; otherwise NIL.
547 t)))
549 ;;; Restore a TN with a :SAVE-ONCE save TN.
557 ;;; Save a single TN that needs to be saved, choosing save-once if
558 ;;; appropriate. This is also called by SPILL-AND-PACK-LOAD-TN.
570 ;;; Scan over the VOPs in BLOCK, emiting saving code for TNs noted in
571 ;;; the codegen info that are packed into saved SCs.
583 \f
584 ;;;; optimized saving
586 ;;; Save TN if it isn't a single-writer TN that has already been
587 ;;; saved. If multi-write, we insert the save BEFORE the specified
588 ;;; VOP. CONTEXT is a VOP used to tell which node/block to use for the
589 ;;; new VOP.
599 tn save before))))
602 ;;; Load the TN from its save location, allocating one if necessary.
603 ;;; The load is inserted BEFORE the specified VOP. CONTEXT is a VOP
604 ;;; used to tell which node/block to use for the new VOP.
609 save tn before))
612 ;;; Start scanning backward at the end of BLOCK, looking which TNs are
613 ;;; live and looking for places where we have to save. We manipulate
614 ;;; two sets: SAVES and RESTORES.
615 ;;;
616 ;;; SAVES is a set of all the TNs that have to be saved because they
617 ;;; are restored after some call. We normally delay saving until the
618 ;;; beginning of the block, but we must save immediately if we see a
619 ;;; write of the saved TN. We also immediately save all TNs and exit
620 ;;; when we see a NOTE-ENVIRONMENT-START VOP, since saves can't be
621 ;;; done before the environment is properly initialized.
622 ;;;
623 ;;; RESTORES is a set of all the TNs read (and not written) between
624 ;;; here and the next call, i.e. the set of TNs that must be restored
625 ;;; when we reach the next (earlier) call VOP. Unlike SAVES, this set
626 ;;; is cleared when we do the restoring after a call. Any TNs that
627 ;;; were in RESTORES are moved into SAVES to ensure that they are
628 ;;; saved at some point.
629 ;;;
630 ;;; SAVES and RESTORES are represented using both a list and a
631 ;;; bit-vector so that we can quickly iterate and test for membership.
632 ;;; The incoming SAVES and RESTORES args are used for computing these
633 ;;; sets (the initial contents are ignored.)
634 ;;;
635 ;;; When we hit a VOP with :COMPUTE-ONLY SAVE-P (an internal error
636 ;;; location), we pretend that all live TNs were read, unless (= speed
637 ;;; 3), in which case we mark all the TNs that are live but not
638 ;;; restored as spilled.
662 prev)
710 (:compute-only
725 ;;; This is like EMIT-SAVES, only different. We avoid redundant saving
726 ;;; within the block, and don't restore values that aren't used before
727 ;;; the next call. This function is just the top level loop over the
728 ;;; blocks in the component, which locates blocks that need saving
729 ;;; done.
747 ;;; Iterate over the normal TNs, finding the cost of packing on the
748 ;;; stack in units of the number of references. We count all
749 ;;; references as +1, and subtract out REGISTER-SAVE-PENALTY for each
750 ;;; place where we would have to save a register.
772 ;;; Iterate over the normal TNs, storing the depth of the deepest loop
773 ;;; that the TN is used in TN-LOOP-DEPTH.
789 ;; What does "references in this VOP
790 ;; mean"? Probably something that isn't
791 ;; useful in this context, since these
792 ;; TN-REFs are linked with TN-REF-NEXT
793 ;; instead of TN-REF-ACROSS. --JES
794 ;; 2004-09-11
795 ;; (find-all-tns #'vop-refs)
796 ))
805 \f
806 ;;;; load TN packing
808 ;;; These variables indicate the last location at which we computed
809 ;;; the Live-TNs. They hold the BLOCK and VOP values that were passed
810 ;;; to COMPUTE-LIVE-TNS.
814 ;;; If we unpack some TNs, then we mark all affected blocks by
815 ;;; sticking them in this hash-table. This is initially null. We
816 ;;; create the hashtable if we do any unpacking.
820 ;;; Set the LIVE-TNS vectors in all :FINITE SBs to represent the TNs
821 ;;; live at the end of BLOCK.
831 ;; KLUDGE: we can have "live" TNs that are neither read
832 ;; to nor written from, due to more aggressive (type-
833 ;; directed) constant propagation. Such TNs will never
834 ;; be assigned an offset nor be in conflict with anything.
835 ;;
836 ;; Ideally, it seems to me we could make sure these TNs
837 ;; are never allocated in the first place in
838 ;; ASSIGN-LAMBDA-VAR-TNS.
853 ;;; Set the LIVE-TNs in :FINITE SBs to represent the TNs live
854 ;;; immediately after the evaluation of VOP in BLOCK, excluding
855 ;;; results of the VOP. If VOP is null, then compute the live TNs at
856 ;;; the beginning of the block. Sequential calls on the same block
857 ;;; must be in reverse VOP order.
908 ;;; This is kind of like OFFSET-CONFLICTS-IN-SB, except that it uses
909 ;;; the VOP refs to determine whether a Load-TN for OP could be packed
910 ;;; in the specified location, disregarding conflicts with TNs not
911 ;;; referenced by this VOP. There is a conflict if either:
912 ;;; 1. The reference is a result, and the same location is either:
913 ;;; -- Used by some other result.
914 ;;; -- Used in any way after the reference (exclusive).
915 ;;; 2. The reference is an argument, and the same location is either:
916 ;;; -- Used by some other argument.
917 ;;; -- Used in any way before the reference (exclusive).
918 ;;;
919 ;;; In 1 (and 2) above, the first bullet corresponds to result-result
920 ;;; (and argument-argument) conflicts. We need this case because there
921 ;;; aren't any TN-REFs to represent the implicit reading of results or
922 ;;; writing of arguments.
923 ;;;
924 ;;; The second bullet corresponds to conflicts with temporaries or
925 ;;; between arguments and results.
926 ;;;
927 ;;; We consider both the TN-REF-TN and the TN-REF-LOAD-TN (if any) to
928 ;;; be referenced simultaneously and in the same way. This causes
929 ;;; load-TNs to appear live to the beginning (or end) of the VOP, as
930 ;;; appropriate.
931 ;;;
932 ;;; We return a conflicting TN if there is a conflict.
942 (< offset
945 tn)))
969 ;;; Iterate over all the elements in the SB that would be allocated by
970 ;;; allocating a TN in SC at Offset, checking for conflict with
971 ;;; load-TNs or other TNs (live in the LIVE-TNS, which must be set
972 ;;; up.) We also return true if there aren't enough locations after
973 ;;; Offset to hold a TN in SC. If Ignore-Live is true, then we ignore
974 ;;; the live-TNs, considering only references within Op's VOP.
975 ;;;
976 ;;; We return a conflicting TN, or :OVERFLOW if the TN won't fit.
990 ;;; If a load-TN for OP is targeted to a legal location in SC, then
991 ;;; return the offset, otherwise return NIL. We see whether the target
992 ;;; of the operand is packed, and try that location. There isn't any
993 ;;; need to chain down the target path, since everything is packed
994 ;;; now.
995 ;;;
996 ;;; We require the target to be in SC (and not merely to overlap with
997 ;;; SC). This prevents SC information from being lost in load TNs (we
998 ;;; won't pack a load TN in ANY-REG when it is targeted to a
999 ;;; DESCRIPTOR-REG.) This shouldn't hurt the code as long as all
1000 ;;; relevant overlapping SCs are allowed in the operand SC
1001 ;;; restriction.
1011 loc
1012 nil)))))
1014 ;;; Select a legal location for a load TN for Op in SC. We just
1015 ;;; iterate over the SC's locations. If we can't find a legal
1016 ;;; location, return NIL.
1020 ;; Check any target location first.
1036 ;;; Make TN's location the same as for its save TN (allocating a save
1037 ;;; TN if necessary.) Delete any save/restore code that has been
1038 ;;; emitted thus far. Mark all blocks containing references as needing
1039 ;;; to be repacked.
1060 ;;; This is called by PACK-LOAD-TN where there isn't any location free
1061 ;;; that we can pack into. What we do is move some live TN in one of
1062 ;;; the specified SCs to memory, then mark all blocks that reference
1063 ;;; the TN as needing repacking. If we succeed, we throw to UNPACKED-TN.
1064 ;;; If we fail, we return NIL.
1065 ;;;
1066 ;;; We can unpack any live TN that appears in the NORMAL-TNs list
1067 ;;; (isn't wired or restricted.) We prefer to unpack TNs that are not
1068 ;;; used by the VOP. If we can't find any such TN, then we unpack some
1069 ;;; argument or result TN. The only way we can fail is if all
1070 ;;; locations in SC are used by load-TNs or temporaries in VOP.
1112 nil)
1114 ;;; Try to pack a load TN in the SCs indicated by Load-SCs. If we run
1115 ;;; out of SCs, then we unpack some TN and try again. We return the
1116 ;;; packed load TN.
1117 ;;;
1118 ;;; Note: we allow a Load-TN to be packed in the target location even
1119 ;;; if that location is in a SC not allowed by the primitive type.
1120 ;;; (The SC must still be allowed by the operand restriction.) This
1121 ;;; makes move VOPs more efficient, since we won't do a move from the
1122 ;;; stack into a non-descriptor any-reg through a descriptor argument
1123 ;;; load-TN. This does give targeting some real semantics, making it
1124 ;;; not a pure advisory to pack. It allows pack to do some packing it
1125 ;;; wouldn't have done before.
1156 ;;; Scan a list of load-SCs vectors and a list of TN-REFS threaded by
1157 ;;; TN-REF-ACROSS. When we find a reference whose TN doesn't satisfy
1158 ;;; the restriction, we pack a Load-TN and load the operand into it.
1159 ;;; If a load-tn has already been allocated, we can assume that the
1160 ;;; restriction is satisfied.
1165 ;; Check the targeted operands first.
1198 ;;; Scan the VOPs in BLOCK, looking for operands whose SC restrictions
1199 ;;; aren't satisfied. We do the results first, since they are
1200 ;;; evaluated later, and our conflict analysis is a backward scan.
1213 \f
1214 ;;;; targeting
1216 ;;; Link the TN-REFS READ and WRITE together using the TN-REF-TARGET
1217 ;;; when this seems like a good idea. Currently we always do, as this
1218 ;;; increases the success of load-TN targeting.
1221 ;; As per the comments at the definition of TN-REF-TARGET, read and
1222 ;; write refs are always paired, with TARGET in the read pointing to
1223 ;; the write and vice versa.
1229 ;;; If TN can be packed into SC so as to honor a preference to TARGET,
1230 ;;; then return the offset to pack at, otherwise return NIL. TARGET
1231 ;;; must be already packed.
1238 ;; We can honor a preference if:
1239 ;; -- TARGET's location is in SC's locations.
1240 ;; -- The element sizes of the two SCs are the same.
1241 ;; -- TN doesn't conflict with target's location.
1248 loc
1249 nil)))
1251 ;;; Scan along the target path from TN, looking at readers or writers.
1252 ;;; When we find a packed TN, return CHECK-OK-TARGET of that TN. If
1253 ;;; there is no target, or if the TN has multiple readers (writers),
1254 ;;; then we return NIL. We also always return NIL after 10 iterations
1255 ;;; to get around potential circularity problems.
1256 ;;;
1257 ;;; FIXME: (30 minutes of reverse engineering?) It'd be nice to
1258 ;;; rewrite the header comment here to explain the interface and its
1259 ;;; motivation, and move remarks about implementation details (like
1260 ;;; 10!) inside.
1271 refs
1283 \f
1284 ;;;; location selection
1286 ;;; Select some location for TN in SC, returning the offset if we
1287 ;;; succeed, and NIL if we fail.
1288 ;;;
1289 ;;; For :UNBOUNDED SCs just find the smallest correctly aligned offset
1290 ;;; where the TN doesn't conflict with the TNs that have already been
1291 ;;; packed. For :FINITE SCs try to pack the TN into the most heavily
1292 ;;; used locations first (as estimated in FIND-LOCATION-USAGE).
1293 ;;;
1294 ;;; Historically SELECT-LOCATION tried did the opposite and tried to
1295 ;;; distribute the TNs evenly across the available locations. At least
1296 ;;; on register-starved architectures (x86) this seems to be a bad
1297 ;;; strategy. -- JES 2004-09-11
1312 align-mask))
1313 align-mask)))))))
1324 repeat element-size
1327 offset))))))
1334 ;;; If a save TN, return the saved TN, otherwise return TN. This is
1335 ;;; useful for getting the conflicts of a TN that might be a save TN.
1340 tn))
1341 \f
1342 ;;;; pack interface
1344 ;;; Attempt to pack TN in all possible SCs, first in the SC chosen by
1345 ;;; representation selection, then in the alternate SCs in the order
1346 ;;; they were specified in the SC definition. If the TN-COST is
1347 ;;; negative, then we don't attempt to pack in SCs that must be saved.
1348 ;;; If Restricted, then we can only pack in TN-SC, not in any
1349 ;;; Alternate-SCs.
1350 ;;;
1351 ;;; If we are attempting to pack in the SC of the save TN for a TN
1352 ;;; with a :SPECIFIED-SAVE TN, then we pack in that location, instead
1353 ;;; of allocating a new stack location.
1393 ;;; Pack a wired TN, checking that the offset is in bounds for the SB,
1394 ;;; and that the TN doesn't conflict with some other TN already packed
1395 ;;; in that location. If the TN is wired to a location beyond the end
1396 ;;; of a :UNBOUNDED SB, then grow the SB enough to hold the TN.
1397 ;;;
1398 ;;; ### Checking for conflicts is disabled for :SPECIFIED-SAVE TNs.
1399 ;;; This is kind of a hack to make specifying wired stack save
1400 ;;; locations for local call arguments (such as OLD-FP) work, since
1401 ;;; the caller and callee OLD-FP save locations may conflict when the
1402 ;;; save locations don't really (due to being in different frames.)
1415 ;; For non-x86 ports the presence of a save-tn associated with a
1416 ;; tn is used to identify the old-fp and return-pc tns. It depends
1417 ;; on the old-fp and return-pc being passed in registers.
1423 ;; Use the above check, but only print a verbose warning. This can
1424 ;; be helpful for debugging the x86 port.
1425 #+nil
1429 tn: ~S; tn-kind: ~S~% ~
1430 sc: ~S~% ~
1431 sb: ~S; sb-name: ~S; sb-kind: ~S~% ~
1432 offset: ~S; end: ~S~% ~
1433 original ~S~% ~
1434 tn-save-tn: ~S; tn-kind of tn-save-tn: ~S~%"
1437 offset end
1438 original
1441 ;; On the x86 ports the old-fp and return-pc are often passed on
1442 ;; the stack so the above hack for the other ports does not always
1443 ;; work. Here the old-fp and return-pc tns are identified by being
1444 ;; on the stack in their standard save locations.
1457 ;;; KLUDGE: Prior to SBCL version 0.8.9.xx, this function was known as
1458 ;;; PACK-BEFORE-GC-HOOK, but was non-functional since approximately
1459 ;;; version 0.8.3.xx since the removal of GC hooks from the system.
1460 ;;; This currently (as of 2004-04-12) runs now after every call to
1461 ;;; PACK, rather than -- as was originally intended -- once per GC
1462 ;;; cycle; this is probably non-optimal, and might require tuning,
1463 ;;; maybe to be called when the data structures exceed a certain size,
1464 ;;; or maybe once every N times. The KLUDGE is that this rewrite has
1465 ;;; done nothing to improve the reentrance or threadsafety of the
1466 ;;; compiler; it still fails to be callable from several threads at
1467 ;;; the same time.
1468 ;;;
1469 ;;; Brief experiments indicate that during a compilation cycle this
1470 ;;; causes about 10% more consing, and takes about 1%-2% more time.
1471 ;;;
1472 ;;; -- CSR, 2004-04-12
1480 :initial-element
1482 ;; The cross-compiler isn't very good at
1483 ;; dumping specialized arrays, so we delay
1484 ;; construction of this SIMPLE-BIT-VECTOR
1485 ;; until runtime.
1489 :initial-element
1491 ;; Ibid
1506 collect lambda
1511 new-path
1524 most-positive-fixnum
1533 ;; Determine whether we want to do more expensive packing by
1534 ;; checking whether any blocks in the component have (> SPEED
1535 ;; COMPILE-SPEED).
1536 ;;
1537 ;; FIXME: This means that a declaration can have a minor
1538 ;; effect even outside its scope, and as the packing is done
1539 ;; component-globally it'd be tricky to use strict scoping. I
1540 ;; think this is still acceptable since it's just a tradeoff
1541 ;; between compilation speed and allocation quality and
1542 ;; doesn't affect the semantics of the generated code in any
1543 ;; way. -- JES 2004-10-06
1550 ;; Call the target functions.
1558 ;; Pack wired TNs first.
1563 ;; Pack restricted component TNs.
1569 ;; Pack other restricted TNs.
1575 ;; Assign costs to normal TNs so we know which ones should
1576 ;; always be packed on the stack.
1581 ;; Allocate normal TNs, starting with the TNs that are used
1582 ;; in deep loops. Only allocate in finite SCs (i.e. not on
1583 ;; the stack).
1594 ;; If loop analysis has been disabled we might as
1595 ;; well revert to the old behaviour of just
1596 ;; packing TNs linearly as they appear.
1605 t)
1613 ;; Pack any leftover normal TNs that could not be allocated
1614 ;; to finite SCs, or TNs that do not appear in any local TN
1615 ;; map (e.g. :MORE TNs). Since we'll likely be allocating
1616 ;; on the stack, first allocate TNs that are associated with
1617 ;; code at shallow lexical depths: this will allocate long
1618 ;; live ranges (i.e. TNs with more conflicts) first, and
1619 ;; hopefully minimise stack fragmentation.
1620 ;;
1621 ;; Collect in reverse order to give priority to older TNs.
1637 ;; first pack TNs that are known to have simple
1638 ;; live ranges (contiguous lexical scopes)
1642 ;; Do load TN packing and emit saves.