Change 1c9e8235ac made it so that fdefn of NIL is not physically in NIL.
Granted nothing should invoke (FIND-OR-CREATE-FDEFN NIL),
but it's best to prevent a disaster when we can.
The C code should not fail on these inputs, and there's not much I can do
without thoroughly grokking Bob Jenkins' code, but two things can work better:
(1) the API I made was broken in that it didn't detect the failure
(2) if it does fail on a set of exactly 2^N keys, where minimal-perfect is
the same as "non-minimal" perfect, try either. It might magically work.
So now NIL's name-hash is 0 given that static space is below 4GB
and the SYMBOL-NAME-HASH accessor is simply a 32-bit MOV.
Also put 1 random byte in the hash slot so that SYMBOL-HASH is a
slightly better hash function for EQL,EQUAL,EQUALP tables.
The symbol hashing functions required for cross-compiling entailed too much
use of #+/- and were strewn across too many files. Fix that, and also make
clear distinctions between the flavors of hash you might want: pseudo-random,
or strictly based on chars of the name. SXHASH isn't always the right choice.
See in particular the large comment added to src/compiler/sxhash.
* Get rid of all logic that worked around hash collisions.
Either find a perfect hash or else expand in the naive if/else way.
This gives better semantics by not having unused value array elements
of branches of the resulting COND.
* Allow FIXNUM and CHARACTER as keys, possibly a mixture of them.
* Instead of only recognizing self-evaluating objects in clause consequents
call CONSTANTP on each.
* Pass unmodified clauses to the macroexpander helper function so that
it doesn't have to reverse-engineer all the (EQL x 'obj) tests.
These are created by an ensuing commit, but it seems like commit emails
get lost when the diff exceeds a certain number of lines, and even if not,
this diff would cause clipping of the body of what is otherwise not
actually a very large change.
If we see a CASE macro with keys 1..39 and 50, the expander would like to
know whether it should remap those into the range 0..39 via perfect hash
(or something), versus whether IR2 would accept the keys set as-is.
So the front- and back-ends have to agree on the limitations.
* The :MACROLET-NOT-IMMOBILE-SPACE test asserts that macroexpanders compile only
into dynamic space. No transform thus far has broken the test (because FIND etc
transforms are not macros) and while I look forward to a day when text space is
not such a precious resource, this prevents an impending failure.
* A few new xperfecthash entries will need > 3 temps in the 32-bit-codegen test.
CL's PACKAGE-USE-LIST is conceptually a set, and implementations
are (empirically) allowed to return the packages in any order. Remove
the sensitivity of cold-sbcl.core to this host implementation decision
by sorting the package names in the use list before adding to
our *package-graph*.
After this change, cold-sbcl.core as produced by cmucl and sbcl are
identical. There remains some non-determinism in the post-cold-init
build.
NIL-as-cons is overlayed with SYMBOL-FDEFN which is better since that's
supposed to be NIL. Wth newfound freedom, assign NIL a name-based hash
so that the xperfecthash30 file is insensitive to NIL's address.
And every so often you should rearrange primitive object slots anyway
to ascertain that it's not impossible.
