bug#70474: [PATCH] Move the spin loop target to the LDAXR instruction.

Oh man. This little patch all by itself makes the problem behaviour go 
away. No switching to SWPAL/CASAL, just tightening the spinloop. (And no 
changes at all to the CAS code, so nothing to do with the fibers bug I 
guess.)

With the patch, the spinloop goes LDAXR-STLXR-CBNZ (which is what GCC 
does when SWPAL isn't there) instead of potentially MOV-LDAXR-STLXR-CBNZ 
(which isn't).

Could the machine really be so sensitive to the target of the CBNZ?

---
  libguile/lightening/lightening/aarch64-cpu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libguile/lightening/lightening/aarch64-cpu.c 
b/libguile/lightening/lightening/aarch64-cpu.c
index 13aa351e9..4df712a0e 100644
--- a/libguile/lightening/lightening/aarch64-cpu.c
+++ b/libguile/lightening/lightening/aarch64-cpu.c
@@ -2532,10 +2532,10 @@ str_atomic(jit_state_t *_jit, int32_t loc, 
int32_t val)
  static void
  swap_atomic(jit_state_t *_jit, int32_t dst, int32_t loc, int32_t val)
  {
-  void *retry = jit_address(_jit);
    int32_t result = jit_gpr_regno(get_temp_gpr(_jit));
    int32_t val_or_tmp = dst == val ? jit_gpr_regno(get_temp_gpr(_jit)) 
: val;
    movr(_jit, val_or_tmp, val);
+  void *retry = jit_address(_jit);
    LDAXR(_jit, dst, loc);
    STLXR(_jit, val_or_tmp, loc, result);
    jit_patch_there(_jit, bnei(_jit, result, 0), retry);
-- 
2.44.0