Re: [Sbcl-devel] [Sbcl-commits] master: x86-64: use dword LEA when referencing entries in immobile code.

[Douglas Katzman via Sbcl-devel]

I would prefer not to hide assumptions that immobile space is below 2GB.  I plan to remove that restriction very soon.  Immobile-symbols and layouts will still use 32-bit pointers, but not code and not FDEFNs.

On Mon, Oct 23, 2023 at 8:10 PM stassats via Sbcl-commits <sbcl-c...@lists.sourceforge.net> wrote:

The branch "master" has been updated in SBCL:
       via  5b39c304a0832e85e8f463a0ff4215a79ad6f222 (commit)
      from  907b3c97c01aa30754bea5293893947650ddbd78 (commit)

- Log -----------------------------------------------------------------
commit 5b39c304a0832e85e8f463a0ff4215a79ad6f222
Author: Stas Boukarev <stas...@gmail.com>
Date:   Tue Oct 24 03:10:25 2023 +0300

    x86-64: use dword LEA when referencing entries in immobile code.
---
 src/compiler/x86-64/alloc.lisp | 11 +++++++++--
 src/compiler/x86-64/nlx.lisp   | 12 ++++++++++--
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/compiler/x86-64/alloc.lisp b/src/compiler/x86-64/alloc.lisp
index 36af81181..912361b11 100644
--- a/src/compiler/x86-64/alloc.lisp
+++ b/src/compiler/x86-64/alloc.lisp
@@ -934,14 +934,21 @@
                           (inst or temp layout)))
                    temp)
                  result 0 fun-pointer-lowtag (not stack-allocate-p))
-        (inst lea temp (rip-relative-ea label (ash simple-fun-insts-offset word-shift)))
+        (inst lea (if (sb-c::code-immobile-p vop)
+                      :dword
+                      :qword)
+              temp (rip-relative-ea label (ash simple-fun-insts-offset word-shift)))
         (storew temp result closure-fun-slot fun-pointer-lowtag)))))

 (define-vop (reference-closure)
   (:info label)
   (:results (result :scs (descriptor-reg)))
+  (:vop-var vop)
   (:generator 1
-    (inst lea result (rip-relative-ea label fun-pointer-lowtag))))
+    (inst lea (if (sb-c::code-immobile-p vop)
+                  :dword
+                  :qword)
+      result (rip-relative-ea label fun-pointer-lowtag))))

 ;;; The compiler likes to be able to directly make value cells.
 (define-vop (make-value-cell)
diff --git a/src/compiler/x86-64/nlx.lisp b/src/compiler/x86-64/nlx.lisp
index 0504e3684..a5193efc8 100644
--- a/src/compiler/x86-64/nlx.lisp
+++ b/src/compiler/x86-64/nlx.lisp
@@ -54,12 +54,16 @@
   #+sb-thread
   (:temporary (:sc complex-double-reg) xmm-temp)
   (:results (block :scs (any-reg)))
+  (:vop-var vop)
   (:generator 22
     (inst lea block (unwind-block-ea tn))
     (load-tl-symbol-value temp *current-unwind-protect-block*)
     (storew temp block unwind-block-uwp-slot)
     (storew rbp-tn block unwind-block-cfp-slot)
-    (inst lea temp (rip-relative-ea entry-label))
+    (inst lea (if (sb-c::code-immobile-p vop)
+                  :dword
+                  :qword)
+      temp (rip-relative-ea entry-label))
     (storew temp block unwind-block-entry-pc-slot)
     #+sb-thread
     (let ((bsp (info :variable :wired-tls '*binding-stack-pointer*)))
@@ -82,12 +86,16 @@
   (:temporary (:sc descriptor-reg) temp)
   #+sb-thread
   (:temporary (:sc complex-double-reg) xmm-temp)
+  (:vop-var vop)
   (:generator 44
     (inst lea block (catch-block-ea tn))
     (load-tl-symbol-value temp *current-unwind-protect-block*)
     (storew temp block catch-block-uwp-slot)
     (storew rbp-tn block catch-block-cfp-slot)
-    (inst lea temp (rip-relative-ea entry-label))
+    (inst lea (if (sb-c::code-immobile-p vop)
+                  :dword
+                  :qword)
+      temp (rip-relative-ea entry-label))
     (storew temp block catch-block-entry-pc-slot)
     (storew tag block catch-block-tag-slot)
     #+sb-thread

-----------------------------------------------------------------------


hooks/post-receive
--
SBCL


_______________________________________________
Sbcl-commits mailing list
Sbcl-c...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-commits

[Stas Boukarev]

I was worried about something like that, but proceeded since there are already instances of that pattern. Should it be expressed differently then, 32-bit-code-p?