## Summary The `simd013` test fails with the `optasm` way: ## Steps to reproduce ``` $ hadrian/build -j --flavour=quick test --only=simd013 --test-way=optasm ... =====> 1 of 1 [0, 0, 0] Actual stdout output differs from expected: --- "/tmp/ghctest-mq9ijjo6/test spaces/testsuite/tests/simd/should_run/simd013.run/simd013.stdout.normalised" 2025-10-27 20:32:56.652755106 +0900 +++ "/tmp/ghctest-mq9ijjo6/test spaces/testsuite/tests/simd/should_run/simd013.run/simd013.run.stdout.normalised" 2025-10-27 20:32:56.652755106 +0900 @@ -1,2 +1,2 @@ (8.8,88.88) -(1111111.9921875,2222222.9921875) +(1111111.9921875,0.0) *** unexpected failure for simd013(optasm) ``` ## Expected behavior The test should succeed. ## Some thoughts This is another issue with incorrect spilling, similar to #25659. I believe `(MOV FF64 (OpReg r) (OpReg dst))` in `vector_float_extract` (https://gitlab.haskell.org/ghc/ghc/-/blob/99d5707f0cb4fcc5901788f86d7065089203a505/compiler/GHC/CmmToAsm/X86/CodeGen.hs#L1798-1822) is problematic, which makes the register allocator think `r` is a `FF64` register. I wonder if it's possible to modify the register allocator to take care of different uses of a vector register -- `FF64` or `VecFormat`. At least, situations like this should be detected by some linting phase (`-dasm-lint`?). ## Environment * GHC version used: 9.15.20251019 (99d5707f0cb4fcc5901788f86d7065089203a505) * Operating System: Ubuntu 24.04 * System Architecture: x86_64