| blob | 1687749193ffa122014417caf572a70c1597e137 |
1 ;;;; optimizers for list and sequence functions
3 ;;;; This software is part of the SBCL system. See the README file for
4 ;;;; more information.
5 ;;;;
6 ;;;; This software is derived from the CMU CL system, which was
7 ;;;; written at Carnegie Mellon University and released into the
8 ;;;; public domain. The software is in the public domain and is
9 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
10 ;;;; files for more information.
13 \f
14 ;;;; mapping onto lists: the MAPFOO functions
16 ;; This expander allows a compiler-macro for FN to take effect by eliding
17 ;; a LET binding of it. Attempting to self-optimize like that isn't the usual
18 ;; SBCL way, however this is a countermeasure to an inhibition of a later
19 ;; optimization, and it is not an onerous change to the expander.
20 ;; We've gone to the trouble of inlining MAPfoo, but the inlined code
21 ;; prevented use of a compiler-macro because %FUNCALL (as opposed to FUNCALL)
22 ;; is not recognized. "Fixing" the compiler to understand %FUNCALL being
23 ;; the same isn't enough: the funarg must be a literal form because we can't
24 ;; know that a variable arg is a never-modified binding of 'F or #'F
25 ;; until IR1 has figured that out, at which point it is too late.
26 ;; [However, see lp# 632368 which asks for something like that.]
27 ;;
28 ;; Also, you might think there to be a subtle difference in behavior from
29 ;; delaying the reference to #'F versus referencing it once. But there is no
30 ;; difference - either way will use the #<fdefn> of F in the call.
31 ;; Of course, it would be ridiculously unportable to to rely on the
32 ;; fact that F can be changed (for its next call) while funcalling it.
33 ;;
40 arglists
51 (:nconc
61 (:list
70 ;; Accumulate using %RPLACD. RPLACD becomes (SETF CDR)
71 ;; which becomes %RPLACD but relies on "defsetfs".
72 ;; This is for effect, not value, so makes no difference.
97 \f
98 ;;;; mapping onto sequences: the MAP function
100 ;;; MAP is %MAP plus a check to make sure that any length specified in
101 ;;; the result type matches the actual result. We also wrap it in a
102 ;;; TRULY-THE for the most specific type we can determine.
107 ;; what we know about the type of the result. (Note that the
108 ;; "result type" argument is not necessarily the type of the
109 ;; result, since NIL means the result has NULL type.)
111 'consed-sequence
115 'null
116 result-type-arg-value)))))
120 ;; ANSI requires the length-related type check only
121 ;; when the SAFETY quality is 3... in other cases, we
122 ;; skip it, because it could be expensive.
123 bare)
126 result-type-arg))
129 result-type)))
136 bare
139 ;; FIXME: this is wrong, as not all subtypes of
140 ;; VECTOR are ARRAY-TYPEs [consider, for
141 ;; example, (OR (VECTOR T 3) (VECTOR T
142 ;; 4))]. However, it's difficult to see what we
143 ;; should put here... maybe we should
144 ;; GIVE-UP-IR1-TRANSFORM if the type is a
145 ;; subtype of VECTOR but not an ARRAY-TYPE?
146 bare))))))))
148 ;;; Return a DO loop, mapping a function FUN to elements of
149 ;;; sequences. SEQS is a list of lvars, SEQ-NAMES - list of variables,
150 ;;; bound to sequences, INTO - a variable, which is used in
151 ;;; MAP-INTO. RESULT and BODY are forms, which can use variables
152 ;;; FUNCALL-RESULT, containing the result of application of FUN, and
153 ;;; INDEX, containing the current position in sequences.
171 for seq-name in seq-names
212 :from-end t
214 body)))))
216 ;;; Try to compile %MAP efficiently when we can determine sequence
217 ;;; argument types at compile time.
218 ;;;
219 ;;; Note: This transform was written to allow open coding of
220 ;;; quantifiers by expressing them in terms of (MAP NIL ..). For
221 ;;; non-NIL values of RESULT-TYPE, it's still useful, but not
222 ;;; necessarily as efficient as possible. In particular, it will be
223 ;;; inefficient when RESULT-TYPE is a SIMPLE-ARRAY with specialized
224 ;;; numeric element types. It should be straightforward to make it
225 ;;; handle that case more efficiently, but it's left as an exercise to
226 ;;; the reader, because the code is complicated enough already and I
227 ;;; don't happen to need that functionality right now. -- WHN 20000410
230 "open code"
237 subtype-p
251 ;; The consing arity-1 cases can be implemented
252 ;; reasonably efficiently as function calls, and the cost
253 ;; of consing should be significantly larger than
254 ;; function call overhead, so we always compile these
255 ;; cases as full calls regardless of speed-versus-space
256 ;; optimization policy.
260 ;; the current open-coded implementation has the
261 ;; same problem.)
277 ;; (We use the same idiom, of returning a LAMBDA from
278 ;; DEFTRANSFORM, as is used in the DEFTRANSFORMs for
279 ;; FUNCALL and ALIEN-FUNCALL, and for the same
280 ;; reason: we need to get the runtime values of each
281 ;; of the &REST vars.)
293 all-seqs seq-args
294 :result result
295 :body push-dacc
301 ;;; MAP-INTO
305 "open code"
309 seqs)))
322 seqs seqs-names
328 funcall-result))
331 seqs seqs-names
337 result)))
339 \f
340 ;;; FIXME: once the confusion over doing transforms with known-complex
341 ;;; arrays is over, we should also transform the calls to (AND (ARRAY
342 ;;; * (*)) (NOT (SIMPLE-ARRAY * (*)))) objects.
368 ;;; True if EQL comparisons involving type can be simplified to EQ.
374 ;; Write "%NAME-FUN1-FUN2-FUN3", etc. Not only is
375 ;; this ever so slightly faster then FORMAT, this
376 ;; way we are also proof against *PRINT-CASE*
377 ;; frobbing and such.
388 function-name key-functions variant)))
395 ;; If TEST is EQL, drop it.
398 ;; Ditto for KEY IDENTITY.
401 ;; Key can legally be NIL, but if it's NIL for sure we pretend it's
402 ;; not there at all. If it might be NIL, make up a form to that
403 ;; ensures it is a function.
447 key-form
457 ;; constant nil list
460 nil))
462 ;; specialized out-of-line version
467 ;; If KEY is IDENTITY, drop it.
470 ;; Key can legally be NIL, but if it's NIL for sure we pretend it's
471 ;; not there at all. If it might be NIL, make up a form to that
472 ;; ensures it is a function.
504 tail))
514 ;; constant nil list -- nothing to find!
515 nil)
517 ;; specialized out-of-line version
549 ',tail
551 nil)))
554 ;;; A similar transform used to apply to MEMBER and ASSOC, but since
555 ;;; TRANSFORM-LIST-ITEM-SEEK now takes care of them those transform
556 ;;; would never fire, and (%MEMBER-TEST ITEM LIST #'EQ) should be
557 ;;; almost as fast as MEMQ.
559 "convert to EQ test"
568 "open code"
584 *
600 "Unknown fill basher, please report to sbcl-devel: ~A"
601 basher-name)))
613 ;; BASH-VALUE is a word that we can repeatedly smash
614 ;; on the array: for less-than-word sized elements it
615 ;; contains multiple copies of the fill item.
624 (:tagged
626 (:char
628 (:bits
629 tmp)
630 (:single-float
633 (:double-float
637 (:complex-single-float
646 res))
651 (:tagged
653 (:char
655 (:bits
657 (:single-float
660 (:double-float
664 (:complex-single-float
676 res)))))
678 ;; KLUDGE: WITH-ARRAY data in its full glory is going to mess up
679 ;; dynamic-extent for MAKE-ARRAY :INITIAL-ELEMENT initialization.
684 ;; Minor abuse %CHECK-BOUND for bounds checking.
685 ;; (- END START) may still end up negative, but
686 ;; the basher handle that.
690 start)))
699 seq))
709 ;; WITH-ARRAY-DATA did our range checks once and for all, so
710 ;; it'd be wasteful to check again on every AREF...
716 ;; ... though we still need to check that the new element can fit
717 ;; into the vector in safe code. -- CSR, 2002-07-05
727 :start start
729 \f
730 ;;;; hairy sequence transforms
732 ;;; FIXME: no hairy sequence transforms in SBCL?
733 ;;;
734 ;;; There used to be a bunch of commented out code about here,
735 ;;; containing the (apparent) beginning of hairy sequence transform
736 ;;; infrastructure. People interested in implementing better sequence
737 ;;; transforms might want to look at it for inspiration, even though
738 ;;; the actual code is ancient CMUCL -- and hence bitrotted. The code
739 ;;; was deleted in 1.0.7.23.
740 \f
741 ;;;; string operations
743 ;;; We transform the case-sensitive string predicates into a non-keyword
744 ;;; version. This is an IR1 transform so that we don't have to worry about
745 ;;; changing the order of evaluation.
749 * *)
758 ;;; Return a form that tests the free variables STRING1 and STRING2
759 ;;; for the ordering relationship specified by LESSP and EQUALP. The
760 ;;; start and end are also gotten from the environment. Both strings
761 ;;; must be SIMPLE-BASE-STRINGs.
768 string1 start1 end1 string2 start2 end2)))
778 (+ index
781 start1))))))
782 index)
826 `(,',result-fun
835 ;; An IF node doesn't care about the mismatch index.
836 ;; Transforming to (not (string= ..)) would lead to internal confusion
837 ;; due to incorrect typing: STRING/= can't return T, so return 0 for true.
843 \f
844 ;;;; transforms for sequence functions
846 ;;; Moved here from generic/vm-tran.lisp to satisfy clisp. Only applies
847 ;;; to vectors based on simple arrays.
851 ;;; FIXME: In the copy loops below, we code the loops in a strange
852 ;;; fashion:
853 ;;;
854 ;;; (do ((i (+ src-offset length) (1- i)))
855 ;;; ((<= i 0) ...)
856 ;;; (... (aref foo (1- i)) ...))
857 ;;;
858 ;;; rather than the more natural (and seemingly more efficient):
859 ;;;
860 ;;; (do ((i (1- (+ src-offset length)) (1- i)))
861 ;;; ((< i 0) ...)
862 ;;; (... (aref foo i) ...))
863 ;;;
864 ;;; (more efficient because we don't have to do the index adjusting on
865 ;;; every iteration of the loop)
866 ;;;
867 ;;; We do this to avoid a suboptimality in SBCL's backend. In the
868 ;;; latter case, the backend thinks I is a FIXNUM (which it is), but
869 ;;; when used as an array index, the backend thinks I is a
870 ;;; POSITIVE-FIXNUM (which it is). However, since the backend thinks of
871 ;;; these as distinct storage classes, it cannot coerce a move from a
872 ;;; FIXNUM TN to a POSITIVE-FIXNUM TN. The practical effect of this
873 ;;; deficiency is that we have two extra moves and increased register
874 ;;; pressure, which can lead to some spectacularly bad register
875 ;;; allocation. (sub-FIXME: the register allocation even with the
876 ;;; strangely written loops is not always excellent, either...). Doing
877 ;;; it the first way, above, means that I is always thought of as a
878 ;;; POSITIVE-FIXNUM and there are no issues.
879 ;;;
880 ;;; Besides, the *-WITH-OFFSET machinery will fold those index
881 ;;; adjustments in the first version into the array addressing at no
882 ;;; performance penalty!
884 ;;; This transform is critical to the performance of string streams. If
885 ;;; you tweak it, make sure that you compare the disassembly, if not the
886 ;;; performance of, the functions implementing string streams
887 ;;; (e.g. SB!IMPL::STRING-OUCH).
892 ,sequence-type1
909 n-element-bits)
912 seq1 start1 replace-len)))
915 ;; If the sequence types are different, SEQ1 and
916 ;; SEQ2 must be distinct arrays.
932 seq1))))
940 into forms
945 #!+sb-unicode
950 ;;; Expand simple cases of UB<SIZE>-BASH-COPY inline. "simple" is
951 ;;; defined as those cases where we are doing word-aligned copies from
952 ;;; both the source and the destination and we are copying from the same
953 ;;; offset from both the source and the destination. (The last
954 ;;; condition is there so we can determine the direction to copy at
955 ;;; compile time rather than runtime. Remember that UB<SIZE>-BASH-COPY
956 ;;; acts like memmove, not memcpy.) These conditions may seem rather
957 ;;; restrictive, but they do catch common cases, like allocating a (* 2
958 ;;; N)-size buffer and blitting in the old N-size buffer in.
961 dst dst-offset
962 length n-elems-per-word)
969 ;; Avoid non-word aligned copies.
972 ;; Avoid copies where we would have to insert code for
973 ;; determining the direction of copying.
976 ;; FIXME: The cross-compiler doesn't optimize TRUNCATE properly,
977 ;; so we have to do its work here.
979 'length
982 ;; Handle any bits at the end.
985 ;; FIXME: The shift amount on this ASH is
986 ;; *always* negative, but the backend doesn't
987 ;; have a NEGATIVE-FIXNUM primitive type, so we
988 ;; wind up with a pile of code that tests the
989 ;; sign of the shift count prior to shifting when
990 ;; all we need is a simple negate and shift
991 ;; right. Yuck.
1009 ;; Copy from the end to save a register.
1020 dst dst-offset
1021 length)
1026 index)
1027 *)
1029 dst dst-offset length
1034 ;;; We expand copy loops inline in SUBSEQ and COPY-SEQ if we're copying
1035 ;;; arrays with elements of size >= the word size. We do this because
1036 ;;; we know the arrays cannot alias (one was just consed), therefore we
1037 ;;; can determine at compile time the direction to copy, and for
1038 ;;; word-sized elements, UB<WORD-SIZE>-BASH-COPY will do a bit of
1039 ;;; needless checking to figure out what's going on. The same
1040 ;;; considerations apply if we are copying elements larger than the word
1041 ;;; size, with the additional twist that doing it inline is likely to
1042 ;;; cons far less than calling REPLACE and letting generic code do the
1043 ;;; work.
1044 ;;;
1045 ;;; However, we do not do this for elements whose size is < than the
1046 ;;; word size because we don't want to deal with any alignment issues
1047 ;;; inline. The UB*-BASH-COPY transforms might fix things up later
1048 ;;; anyway.
1052 ;; The two transforms that use this test already specify that their
1053 ;; sequence argument is a VECTOR,
1054 ;; so this seems like it would be more efficient as
1055 ;; and (not (array-type-complexp type))
1056 ;; (not (eq (array-type-element-type type) *wild-type*))
1057 ;; Anyway it no longer works to write this as a single specifier
1058 ;; '(or (simple-unboxed-array (*)) simple-vector) because that
1059 ;; type is just (simple-array * (*)) which isn't amenable to
1060 ;; inline copying since we don't know what it holds.
1065 element-type)
1079 ;; KLUDGE: The compiler is not able to derive that (+ offset
1080 ;; length) must be a fixnum, but arrives at (unsigned-byte 29).
1081 ;; We, however, know it must be so, as by this point the bounds
1082 ;; have already been checked.
1090 ;;; MAKE-SEQUENCE, SUBSEQ, COPY-SEQ
1107 ;; Require sameness of dim and complexp. Give up on
1108 ;; (OR (VECTOR CHARACTER) (VECTOR BASE-CHAR 2))
1109 ;; which eventually fails in the call to the function.
1113 dim)
1120 types))
1121 dim complexp))))))
1127 ;; VECTOR means (VECTOR T)
1131 ;; Don't transform if size is present in the specifier
1132 ;; and the SIZE argument is not known to be equal.
1135 ;; not sure what it would mean to make it non-simple
1140 ;; no transform, but we can detect some style issues
1149 ;; As with MAKE-ARRAY, this is merely undefined
1150 ;; behavior, not an error.
1152 "The default initial element ~S is not a ~S."
1153 default-initial-element elt-type))))
1154 ;; In would be possible in some cases,
1155 ;; like :INITIAL-ELEMENT (IF X #\x #\y) in a call
1156 ;; to MAKE-SEQUENCE '(VECTOR (MEMBER #\A #\B))
1157 ;; to detect erroneous non-constants initializers,
1158 ;; but it is not important enough to bother with.
1161 elt-ctype)))
1162 ;; MAKE-ARRAY considers this a warning, not an error.
1164 :initial-element
1166 elt-type)))))
1171 *
1190 result))))
1209 result)))
1219 ;;; FIXME: it really should be possible to take advantage of the
1220 ;;; macros used in code/seq.lisp here to avoid duplication of code,
1221 ;;; and enable even funkier transformations.
1225 from-end)
1227 *
1228 :node node
1230 "open code"
1266 end2
1267 start2)))
1274 nil)
1275 ;; INDEX2 is FIXNUM, not an INDEX, as right before the loop
1276 ;; terminates is hits -1 when :FROM-END is true and :START2
1277 ;; is 0.
1295 elt)))
1302 elt)))
1308 ;;; Open-code CONCATENATE for strings. It would be possible to extend
1309 ;;; this transform to non-strings, but I chose to just do the case that
1310 ;;; should cover 95% of CONCATENATE performance complaints for now.
1311 ;;; -- JES, 2007-11-17
1312 ;;;
1313 ;;; Only handle the simple result type cases. If somebody does (CONCATENATE
1314 ;;; '(STRING 6) ...) their code won't be optimized, but nobody does that in
1315 ;;; practice.
1316 ;;;
1317 ;;; Limit full open coding based on length of constant sequences. Default
1318 ;;; value is chosen so that other parts of the compiler (constraint propagation
1319 ;;; mainly) won't go nonlinear too badly. It's not an exact number -- but
1320 ;;; in the right ballpark.
1331 ;; Out-of-line
1339 ;; Inline
1348 for var in vars
1352 sequence)
1353 ,var
1372 for first = t then nil
1373 for value in lvar-values
1374 for var in vars
1375 collect
1378 ;; Fold the array reads for constant arguments
1381 for i from 0
1382 collect
1383 ;; Without truly-the we get massive numbers
1384 ;; of pointless error traps.
1395 (#!+sb-unicode
1398 t)
1399 ,var
1407 .string.))
1408 lvars)))))
1409 \f
1410 ;;;; CONS accessor DERIVE-TYPE optimizers
1413 ;; This and CDR needs to use LVAR-CONSERVATIVE-TYPE because type inference
1414 ;; gets confused by things like (SETF CAR).
1418 null-type)
1426 null-type)
1429 \f
1430 ;;;; FIND, POSITION, and their -IF and -IF-NOT variants
1432 ;;; We want to make sure that %FIND-POSITION is inline-expanded into
1433 ;;; %FIND-POSITION-IF only when %FIND-POSITION-IF has an inline
1434 ;;; expansion, so we factor out the condition into this function.
1438 ;; It's not worth trying to inline vector code unless we
1439 ;; know a fair amount about it at compile time.
1445 ;; Inlining on lists is generally worthwhile.
1446 )
1451 ;;; %FIND-POSITION-IF and %FIND-POSITION-IF-NOT for LIST data
1454 ;; Circularity detection slows things down. It is permissible not to.
1455 ;; In fact, FIND is given as an archetypal example of a function that
1456 ;; "should be prepared to signal an error" but might not [CLHS 1.4.2].
1457 ;; We relax the definition of "safe" from safety=3 to >=2.
1459 ;; The secondary value is inconsequential when flowing into a non-MV
1460 ;; combination, so we avoid counting loop iterations if possible.
1461 ;; This is limited in power, but good enough, for want of a proper
1462 ;; dead-code-elimination phase of the compiler.
1491 ;; If you have as many as INDEX conses on a 32-bit build,
1492 ;; then you've either used up 4GB of memory (impossible)
1493 ;; or you're stuck in a circular list in unsafe code.
1494 ;; Correspondingly larger limit for 64-bit.
1498 ;; This hack of dealing with non-NIL FROM-END for list data
1499 ;; by iterating forward through the list and keeping track of
1500 ;; the last time we found a match might be more screwy than
1501 ;; what the user expects, but it seems to be allowed by the
1502 ;; ANSI standard. (And if the user is screwy enough to ask
1503 ;; for FROM-END behavior on list data, turnabout is fair play.)
1504 ;;
1505 ;; It's also not enormously efficient, calling PREDICATE
1506 ;; and KEY more often than necessary; but all the alternatives
1507 ;; seem to have their own efficiency problems.
1516 *
1517 :node node
1519 "expand inline"
1521 from-end start end node))))
1525 ;;; %FIND-POSITION for LIST data can be expanded into %FIND-POSITION-IF
1526 ;;; without loss of efficiency. (I.e., the optimizer should be able
1527 ;;; to straighten everything out.)
1530 *
1532 "expand inline"
1534 ;; The order of arguments for asymmetric tests
1535 ;; (e.g. #'<, as opposed to order-independent
1536 ;; tests like #'=) is specified in the spec
1537 ;; section 17.2.1 -- the O/Zi stuff there.
1540 sequence
1541 from-end
1542 start
1543 end
1546 ;;; The inline expansions for the VECTOR case are saved as macros so
1547 ;;; that we can share them between the DEFTRANSFORMs and the default
1548 ;;; cases in the DEFUNs. (This isn't needed for the LIST case, because
1549 ;;; the DEFTRANSFORMs for LIST are less choosy about when to expand.)
1551 from-end
1552 start
1553 end-arg
1554 element
1555 done-p-expr)
1564 ;; WITH-ARRAY-DATA has already performed bounds
1565 ;; checking, so we can safely elide the checks
1566 ;; in the inner loop.
1575 ;; (If we aren't fastidious about declaring that
1576 ;; INDEX might be -1, then (FIND 1 #() :FROM-END T)
1577 ;; can send us off into never-never land, since
1578 ;; INDEX is initialized to -1.)
1579 of-type index-or-minus-1
1587 from-end start end key test)
1589 (%find-position-or-find-position-if-vector-expansion
1590 sequence
1591 from-end
1592 start
1593 end
1594 element
1595 ;; (See the LIST transform for a discussion of the correct
1596 ;; argument order, i.e. whether the searched-for ,ITEM goes before
1597 ;; or after the checked sequence element.)
1601 from-end start end key)
1603 (%find-position-or-find-position-if-vector-expansion
1604 sequence
1605 from-end
1606 start
1607 end
1608 element
1612 from-end start end key)
1614 (%find-position-or-find-position-if-vector-expansion
1615 sequence
1616 from-end
1617 start
1618 end
1619 element
1622 ;;; %FIND-POSITION, %FIND-POSITION-IF and %FIND-POSITION-IF-NOT for
1623 ;;; VECTOR data
1626 *
1628 "expand inline"
1630 '(%find-position-if-vector-macro predicate sequence
1631 from-end start end key))
1635 *
1637 "expand inline"
1639 '(%find-position-if-not-vector-macro predicate sequence
1640 from-end start end key))
1644 *
1646 "expand inline"
1648 '(%find-position-vector-macro item sequence
1649 from-end start end key test))
1678 *
1685 sequence
1688 form
1689 ;; Otherwise we'd get three instances of WITH-ARRAY-DATA from
1690 ;; %FIND-POSITION.
1697 ;; The type is known exactly, other transforms will take care of it.
1700 ;;; logic to unravel :TEST, :TEST-NOT, and :KEY options in FIND,
1701 ;;; POSITION-IF, etc.
1709 (,test-not
1710 ;; (Without DYNAMIC-EXTENT, this is potentially horribly
1711 ;; inefficient, but since the TEST-NOT option is deprecated
1712 ;; anyway, we don't care.)
1724 key test test-not)
1727 (%find-position item sequence
1728 from-end start
1729 end
1732 test test-not))))))
1739 end key)
1742 ,values-index
1744 sequence from-end
1745 start end
1750 ;;; the deprecated functions FIND-IF-NOT and POSITION-IF-NOT. We
1751 ;;; didn't bother to worry about optimizing them, except note that on
1752 ;;; Sat, Oct 06, 2001 at 04:22:38PM +0100, Christophe Rhodes wrote on
1753 ;;; sbcl-devel
1754 ;;;
1755 ;;; My understanding is that while the :test-not argument is
1756 ;;; deprecated in favour of :test (complement #'foo) because of
1757 ;;; semantic difficulties (what happens if both :test and :test-not
1758 ;;; are supplied, etc) the -if-not variants, while officially
1759 ;;; deprecated, would be undeprecated were X3J13 actually to produce
1760 ;;; a revised standard, as there are perfectly legitimate idiomatic
1761 ;;; reasons for allowing the -if-not versions equal status,
1762 ;;; particularly remove-if-not (== filter).
1763 ;;;
1764 ;;; This is only an informal understanding, I grant you, but
1765 ;;; perhaps it's worth optimizing the -if-not versions in the same
1766 ;;; way as the others?
1767 ;;;
1768 ;;; FIXME: Maybe remove uses of these deprecated functions within the
1769 ;;; implementation of SBCL.
1773 end key)
1776 ,values-index
1778 sequence from-end
1779 start end
1789 ;; If the bag is constant, use MEMBER
1790 ;; instead of FIND, since we have a
1791 ;; deftransform for MEMBER that can
1792 ;; open-code all of the comparisons when
1793 ;; the list is constant. -- JES, 2007-12-10
1805 index)
1814 end)))
1817 string
1823 \f
1824 ;;; (partially) constant-fold backq-* functions, or convert to their
1825 ;;; plain CL equivalent (now that they're not needed for pprinting).
1827 ;; Pop constant values from the end, list/list* them if any, and link
1828 ;; the remainder with list* at runtime.
1836 constants))
1842 `',tail
1857 ;; Merge adjacent constant values
1873 "Non-list or improper list spliced in ~