x86-64: Treat more symbols as having immediate storage class

Follow-on to https://sourceforge.net/p/sbcl/sbcl/ci/cd8131541577ddd4 -
If immobile-space is enabled, any symbol dumped by the cross-compiler is
in that space. COMPILE-FILE wil detect those symbols by a header bit.

make-target-2-load.lisp

@@ -146,6 +146,22 @@
  ;; SAVE-LISP-AND-DIE.
  #-sb-fluid (!unintern-init-only-stuff)
 
+ ;; Mark interned immobile symbols so that COMPILE-FILE knows
+ ;; which symbols will always be physically in immobile space.
+ ;; Due to the possibility of interning a symbol that was allocated in dynamic
+ ;; space, it's not the case that all interned symbols are immobile.
+ ;; And we can't promise anything across reload, which makes it impossible
+ ;; for x86-64 codegen to know which symbols are immediate constants.
+ ;; Except that symbols which existed at SBCL build time must be.
+ #+(and immobile-space (not immobile-symbols))
+ (do-all-symbols (symbol)
+ (sb-sys:with-pinned-objects (symbol)
+ (let ((addr (sb-kernel:get-lisp-obj-address symbol)))
+ (when (<= sb-vm:immobile-space-start addr sb-vm:immobile-space-end)
+ (sb-kernel:set-header-data
+ symbol (logior (sb-kernel:get-header-data symbol)
+ (ash 1 sb-vm::+initial-core-symbol-bit+)))))))
+
  ;; A symbol whose INFO slot underwent any kind of manipulation
  ;; such that it now has neither properties nor globaldb info,
  ;; can have the slot set back to NIL if it wasn't already.

src/compiler/generic/early-objdef.lisp

@@ -303,6 +303,11 @@
 ;; nonetheless, opportunities for sharing abound.
 (defconstant +vector-shareable-nonstd+ #x200)
 
+;;; This is so that COMPILE-FILE knows that things like :ALLOW-OTHER-KEYS
+;;; can be immediate constants.
+#!+(and immobile-space (not immobile-symbols))
+(defconstant +initial-core-symbol-bit+ 8) ; bit index, not bit value
+
 #|
 ;; Run this in the SB-VM or SB!VM package once for each target feature combo.
 (defun rewrite-widetag-comments ()

src/compiler/x86-64/vm.lisp

@@ -462,16 +462,24 @@
  ((or (integer #.sb!xc:most-negative-fixnum #.sb!xc:most-positive-fixnum)
  character)
  (sc-number-or-lose 'immediate))
- (symbol
- ;; If #!+immobile-symbols, then ALL symbols are static in placement
- ;; and in the sub-2GB space, therefore immediate constants.
- ;; Otherwise, if #!+immobile-space, and either compilation is to memory
- ;; and the symbol is in immobile-space, or if in the cross-compiler which
- ;; dumps all symbols as immobile if possible, then it's immediate.
- (when (or #!+(or immobile-symbols (and immobile-space (host-feature sb-xc-host))) t
- #!+(and immobile-space (not (host-feature sb-xc-host)))
- (and (sb!c::core-object-p sb!c::*compile-object*)
- (typep (get-lisp-obj-address value) '(signed-byte 32)))
+ (symbol ; Symbols in static and immobile space are immediate
+ (when (or ;; With #!+immobile-symbols, all symbols are in immobile-space.
+ ;; And the cross-compiler always uses immobile-space if enabled.
+ #!+(or immobile-symbols (and immobile-space (host-feature sb-xc-host))) t
+
+ ;; Otherwise, if #!-immobile-symbols, and the symbol was present
+ ;; in the initial core image as indicated by the symbol header, then
+ ;; it's in immobile-space. There is a way in which the bit can be wrong,
+ ;; but it's highly unlikely - the symbol would have to be uninterned from
+ ;; the loading SBCL, reallocated in dynamic space and re-interned into its
+ ;; initial package. All without breaking anything. Hence, unlikely.
+ ;; Also note that if compiling to memory, the symbol's current address
+ ;; is used to determine whether it's immediate.
+ #!+(and (not (host-feature sb-xc-host)) immobile-space (not immobile-symbols))
+ (or (logbitp +initial-core-symbol-bit+ (get-header-data value))
+ (and (sb!c::core-object-p sb!c::*compile-object*)
+ (typep (get-lisp-obj-address value) '(signed-byte 32))))
+
  (static-symbol-p value))
  (sc-number-or-lose 'immediate)))
  (single-float