MagicBeanDev/Longshot

Watch

Fork 10

WIP: perf(lift): fast float regions, plain SSE checked once by MXCSR with the exact copy as fallback #38

Draft

dyst wants to merge 4 commits from dyst/Longshot:perf/hot-paths into main

dyst commented

2026-11-12 23:39:05 +00:00

First-time contributor

Why

The frame is bound by the game's own job graph, and its biggest serial steps (Havok AI's character step, Link's movement and collision) are mostly float math that the lifted code runs through an exactness check on every single op, about 25 instructions around each SSE op. This lifts straight runs of that math twice: a plain-SSE copy checked once, and the exact copy kept as the fallback.

What changed

lift: ff_eligible and ff_region in third_party/a64-kit/lift/a64_lift.py: a straight run of instructions with no label, store, call, branch or system-register access, holding at least 8 (A64_FASTFP_MIN) single-precision adds, subtracts, multiplies, fused multiply-adds, divides or square roots, is emitted twice: a fast copy, the ops as plain SSE (asm volatile, in Arm's operand order; multiply-adds as vfmadd231ss on FMA3 builds) between one MXCSR flag clear and one read (a64_ff_begin, a64_ff_end); and the exact copy, the lifted code as before. On an invalid, denormal or underflow flag the registers the run names are put back and the exact copy runs. Divide-by-zero, overflow and inexact are or-ed into FPSR.
lift: Lifter's function emitter gathers joinable instructions into a run (flush), counts ff_regions and ff_ops, and prints a fast float regions (A64_FASTFP=...) line; FASTFP_HEADER is written beside the fpx header when the mode is on.
lift: FASTFP_HEADER: A64_FF_ON gates on the existing RECOMP_FPX_OPEN (FPCR at its defaults apart from FZ, FPSR.IXC set) and on a64_ff_enabled_ (HOS_NO_FASTFP). a64_ff_guard_ raises the invalid flag on purpose for results x86 gets right in value but not in Arm's flags, or not in value under FZ: any NaN result; a product, quotient or multiply-add of exactly 2^-126; a subnormal divided by a zero. The 2-lane vector ops load their upper lanes as zeros. Without FMA3 a multiply-add calls the exact helper inside the fast copy; non-x86 builds compile the exact copy only.
lift: fastfp_mode: A64_FASTFP=0 off; hot the A64_HOT_FUNCS list only (ff_only); check both copies every time, compared (a64_ff_check, fastfp check: lines in the log with counts per chunk and any mismatch's guest address).
tests: tests/test_fastfp_fma.py with tests/fastfp_fma_test.c (new, @Jiro131's, extended) and tests/test_fastfp_regions.py (new).

Flags and settings

Flag	New or changed	What it does	Default now	Goal: on by default?	Helps on	Doesn't help on	Untested on	Untested, but should help on
`HOS_NO_FASTFP`	New (run time)	Any value: the exact copies only, to compare on the same exe	unset (fast copies on)	no (a developer switch)	-	-	-	-
`A64_FASTFP`	New (lift time)	`0` off; `hot` the hot functions only; `check` both copies every time, compared, with `fastfp check:` lines in the log	on (`1`, every function)	yes: on by default in this PR	Ryzen 9 3900X, Windows: Temple of Time 41.5 → 45.7 fps; Havok AI's character step 26% less CPU there, 16% less in Hyrule Town	Hyrule Castle, Ryzen 9 3900X: no change in fps (30.9 → 30.8)	Intel, Linux, CPUs without AVX2 (the SSE path has run only in the unit test)	-
`A64_FASTFP_MIN`	New (lift time)	The fewest float ops a run needs to be made a region	8	no (a developer switch)	-	-	-	-

Measurements

Measured on the GitHub version (NotRexed/Hookshot#2433), not yet on Longshot: this PR stays WIP until it is.

Measured on ebbba2ea, before the rebase and before the result checks of 1e6b7a2f, which add a compare per op.

Hardware: Ryzen 9 3900X, Windows
Scene: Temple of Time; Hyrule Town; Hyrule Castle
Method: alternating runs in the same session (this PC's run-to-run noise is about ±8%); Hyrule Town and Hyrule Castle two alternating pairs each, base against this PR

	GitHub main	this PR (GitHub) @ `ebbba2ea`
Temple of Time, fps (regions without multiply-adds)	41.5	45.7
Temple of Time, Havok AI's character step, ms of CPU a frame	5.6	4.1
Hyrule Castle, fps	30.9	30.8
Hyrule Town, Havok AI's character step, ms of CPU a frame	9.4	7.9
Hyrule Town, the BaseProc executors, ms (two pairs)	118, 121	114, 88
the exe	470 MB	512 MB

Temple of Time with multiply-adds in the regions, against the build without them: 47.1 → 49.1 fps. Sampled, Link's update job takes 19% less time a frame than on main, its collision functions 44–56% less.
Hyrule Castle: the pairs differ by 3 fps between themselves. Hyrule Town: its fps moves between 18 and 25 from run to run of the same exe (the town's own load), so fps can't tell; Havok AI's character step drops in each pair, and the BaseProc executors don't rise.
17,068 regions, 315,994 float ops across the game (47,371 of them multiply-adds; 13,114 regions without them).
The fast copy is kept in 97–99% of runs in each scene, at least 95% in every file.
Check mode, eight saves (Kokiri Forest, Hyrule Field, Hyrule Town, Hyrule Castle, the Deku Tree, Dodongo's Cavern, Jabu-Jabu's Belly, the Water Temple; 42–105 million region runs each): no wrong result. The Water Temple reports 16 mismatches, all in one run (0x831e6808). Rerunning its fast copy from the same inputs gave the exact copy's result every time; the one register that differed holds a float the run loads, which another thread writes between the two copies. Check mode runs each region twice, so it can see that; a normal build loads it once.

Testing

Tested: the runs under Measurements (on the GitHub version) and the game-free checks this description names. Checked but not measured: check mode in eight saves (above), for correctness rather than speed.

Not tested: Intel, Linux and CPUs without AVX2 (the SSE path has run only in the unit test so far). Reports from them are welcome; HOS_NO_FASTFP turns it off on the same exe to compare.

Needs other testers:

Intel CPU (Windows): Kokiri Forest with and without HOS_NO_FASTFP, expecting the same picture, no crash, and its fps (request to open)
A CPU without AVX2: the game starts and plays in Kokiri Forest (request to open)
Linux: the same as on Windows, with and without HOS_NO_FASTFP (request to open)

Screenshots

Nothing on screen.

Risk and rollback

A float result the fast copy gets wrong where the guards don't catch it would change game logic (physics, AI, Link's movement and collision); the result checks and check mode are there to find one.
The exe grows 470 → 512 MB, since both copies are kept.
HOS_NO_FASTFP turns the fast copies off at run time on the same exe; A64_FASTFP=0 lifts without them; reverting the commit is enough.

Reviewer notes

Carried over from NotRexed/Hookshot#2433 with the move to Longshot: the same change on Longshot's main, with its rename applied. Its review and discussion are there (reviewed by Joey-Magnus).

The checks and the game runs above were done on the GitHub version; this branch is the same change with the rename applied (the same files and line counts). Forgejo runs no checks, and they were not run again here.
The change is in third_party/a64-kit/lift/a64_lift.py (the lifter), so the third_party/ box is not ticked.
Since the draft: fused multiply-adds join regions (9f060614, @Jiro131's): they are about half the float ops in Link's movement and collision code, and in Town and Castle one hot file had fallen back to the exact copy in about 55% of runs, which it no longer does. Results Arm doesn't give the same now take the exact copy (1e6b7a2f): the three cases above, found by @Jiro131's tests/test_fastfp_fma.py and by the same test once the divide was added to it; check mode never met them in game. Rebased onto GitHub's main, including NotRexed/Hookshot#2383 (the exact path's single-precision FMA fused on x86-64-v3): the exact copies get it, the fast copies use their own vfmadd231ss.
CI on GitHub: Windows part 1 fails on tests/test_psychov35.py, from NotRexed/Hookshot#2481 on main (scanf is deprecated under -Werror with the runner's MSVC-target clang), not from this PR.
tests/test_fastfp_fma.py: each fast op alone in the MXCSR window against the exact body the lifted code falls back to (recomp_fpe_fma32, _div32, _add32, _sub32; the vector ops lane by lane, 4 lanes and 2), value and FPSR, FZ off and on, with random operands weighted to the underflow and overflow edges, NaNs, subnormals and cancellations, plus an edge list: 0 mismatches in 2–8M checks per op. It fails if any of the result checks is removed, or the 2-lane ops load four lanes.
tests/test_fastfp_regions.py: what may join a region, and a whole region from the real header against plain IEEE results at -march=x86-64-v3 and x86-64-v2 (200,000 random runs; a multiply-add rounded once; NaN results, 0 * inf, a denormal operand and a tiny result under FZ take the exact copy with the inputs put back; overflow and divide-by-zero stay fast with FPSR set; the gate closed or HOS_NO_FASTFP take the exact copy). It fails if the AVX operands are swapped or the invalid flag stops sending a region to its exact copy. It links libm only off Windows.
How to help test: build this branch and play (anything that behaves differently from main is worth a report); or build with A64_FASTFP=check, play anywhere, and look in longshot_log.txt for fastfp check: MISMATCH (there should be none); or compare HOS_THREAD_TIMES=5 with and without HOS_NO_FASTFP on the same exe.

third_party/: this diff changes files under third_party/, which Longshot's rules keep as unmodified upstream copies (a new folder with a PROVENANCE.md instead). That has to be resolved before this can be ready.

Issues

None.

Checklist

For everyone

One topic.
The title is a Conventional Commit (type(scope): description).
Rebased on current main.
python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above).
Tested in the game, or what wasn't is named under Testing.
Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests).
Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
No game files, dumps, build output or generated files.
third_party/ untouched (a new folder with a PROVENANCE.md instead).
The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
Flags table filled in; README / docs/development.md switch reference updated.
Screenshots for a change that shows on screen.
A row in docs/tested-configurations.md for each measured run.
MKWVK_API_VERSION bumped (gpu/vk/vk_api.h's MkwVkHost or MkwVkRenderer changed).
The SPIR-V headers regenerated with glslang (a shader changed).
A game-free test added for the fix, failing on main and passing here.
A check under tests/ that reads changed source updated in this PR, not weakened.
Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths.
Docs updated.

🤖 Generated with Claude Code

## Why The frame is bound by the game's own job graph, and its biggest serial steps (Havok AI's character step, Link's movement and collision) are mostly float math that the lifted code runs through an exactness check on every single op, about 25 instructions around each SSE op. This lifts straight runs of that math twice: a plain-SSE copy checked once, and the exact copy kept as the fallback. ## What changed - lift: `ff_eligible` and `ff_region` in `third_party/a64-kit/lift/a64_lift.py`: a straight run of instructions with no label, store, call, branch or system-register access, holding at least 8 (`A64_FASTFP_MIN`) single-precision adds, subtracts, multiplies, fused multiply-adds, divides or square roots, is emitted twice: a fast copy, the ops as plain SSE (`asm volatile`, in Arm's operand order; multiply-adds as `vfmadd231ss` on FMA3 builds) between one MXCSR flag clear and one read (`a64_ff_begin`, `a64_ff_end`); and the exact copy, the lifted code as before. On an invalid, denormal or underflow flag the registers the run names are put back and the exact copy runs. Divide-by-zero, overflow and inexact are or-ed into FPSR. - lift: `Lifter`'s function emitter gathers joinable instructions into a run (`flush`), counts `ff_regions` and `ff_ops`, and prints a `fast float regions (A64_FASTFP=...)` line; `FASTFP_HEADER` is written beside the fpx header when the mode is on. - lift: `FASTFP_HEADER`: `A64_FF_ON` gates on the existing `RECOMP_FPX_OPEN` (FPCR at its defaults apart from FZ, FPSR.IXC set) and on `a64_ff_enabled_` (`HOS_NO_FASTFP`). `a64_ff_guard_` raises the invalid flag on purpose for results x86 gets right in value but not in Arm's flags, or not in value under FZ: any NaN result; a product, quotient or multiply-add of exactly 2^-126; a subnormal divided by a zero. The 2-lane vector ops load their upper lanes as zeros. Without FMA3 a multiply-add calls the exact helper inside the fast copy; non-x86 builds compile the exact copy only. - lift: `fastfp_mode`: `A64_FASTFP=0` off; `hot` the `A64_HOT_FUNCS` list only (`ff_only`); `check` both copies every time, compared (`a64_ff_check`, `fastfp check:` lines in the log with counts per chunk and any mismatch's guest address). - tests: `tests/test_fastfp_fma.py` with `tests/fastfp_fma_test.c` (new, @Jiro131's, extended) and `tests/test_fastfp_regions.py` (new). ## Flags and settings | Flag | New or changed | What it does | Default now | Goal: on by default? | Helps on | Doesn't help on | Untested on | Untested, but should help on | |---|---|---|---|---|---|---|---|---| | `HOS_NO_FASTFP` | New (run time) | Any value: the exact copies only, to compare on the same exe | unset (fast copies on) | no (a developer switch) | - | - | - | - | | `A64_FASTFP` | New (lift time) | `0` off; `hot` the hot functions only; `check` both copies every time, compared, with `fastfp check:` lines in the log | on (`1`, every function) | yes: on by default in this PR | Ryzen 9 3900X, Windows: Temple of Time 41.5 → 45.7 fps; Havok AI's character step 26% less CPU there, 16% less in Hyrule Town | Hyrule Castle, Ryzen 9 3900X: no change in fps (30.9 → 30.8) | Intel, Linux, CPUs without AVX2 (the SSE path has run only in the unit test) | - | | `A64_FASTFP_MIN` | New (lift time) | The fewest float ops a run needs to be made a region | 8 | no (a developer switch) | - | - | - | - | ## Measurements Measured on the GitHub version (NotRexed/Hookshot#2433), not yet on Longshot: this PR stays WIP until it is. Measured on `ebbba2ea`, before the rebase and before the result checks of 1e6b7a2f, which add a compare per op. Hardware: Ryzen 9 3900X, Windows Scene: Temple of Time; Hyrule Town; Hyrule Castle Method: alternating runs in the same session (this PC's run-to-run noise is about ±8%); Hyrule Town and Hyrule Castle two alternating pairs each, base against this PR | | GitHub main | this PR (GitHub) @ ebbba2ea | |---|---|---| | Temple of Time, fps (regions without multiply-adds) | 41.5 | 45.7 | | Temple of Time, Havok AI's character step, ms of CPU a frame | 5.6 | 4.1 | | Hyrule Castle, fps | 30.9 | 30.8 | | Hyrule Town, Havok AI's character step, ms of CPU a frame | 9.4 | 7.9 | | Hyrule Town, the BaseProc executors, ms (two pairs) | 118, 121 | 114, 88 | | the exe | 470 MB | 512 MB | - Temple of Time with multiply-adds in the regions, against the build without them: 47.1 → 49.1 fps. Sampled, Link's update job takes 19% less time a frame than on main, its collision functions 44–56% less. - Hyrule Castle: the pairs differ by 3 fps between themselves. Hyrule Town: its fps moves between 18 and 25 from run to run of the same exe (the town's own load), so fps can't tell; Havok AI's character step drops in each pair, and the BaseProc executors don't rise. - 17,068 regions, 315,994 float ops across the game (47,371 of them multiply-adds; 13,114 regions without them). - The fast copy is kept in 97–99% of runs in each scene, at least 95% in every file. - Check mode, eight saves (Kokiri Forest, Hyrule Field, Hyrule Town, Hyrule Castle, the Deku Tree, Dodongo's Cavern, Jabu-Jabu's Belly, the Water Temple; 42–105 million region runs each): no wrong result. The Water Temple reports 16 mismatches, all in one run (0x831e6808). Rerunning its fast copy from the same inputs gave the exact copy's result every time; the one register that differed holds a float the run loads, which another thread writes between the two copies. Check mode runs each region twice, so it can see that; a normal build loads it once. ## Testing **Tested:** the runs under Measurements (on the GitHub version) and the game-free checks this description names. Checked but not measured: check mode in eight saves (above), for correctness rather than speed. **Not tested:** Intel, Linux and CPUs without AVX2 (the SSE path has run only in the unit test so far). Reports from them are welcome; `HOS_NO_FASTFP` turns it off on the same exe to compare. **Needs other testers:** - Intel CPU (Windows): Kokiri Forest with and without `HOS_NO_FASTFP`, expecting the same picture, no crash, and its fps (request to open) - A CPU without AVX2: the game starts and plays in Kokiri Forest (request to open) - Linux: the same as on Windows, with and without `HOS_NO_FASTFP` (request to open) ## Screenshots Nothing on screen. ## Risk and rollback - A float result the fast copy gets wrong where the guards don't catch it would change game logic (physics, AI, Link's movement and collision); the result checks and check mode are there to find one. - The exe grows 470 → 512 MB, since both copies are kept. - `HOS_NO_FASTFP` turns the fast copies off at run time on the same exe; `A64_FASTFP=0` lifts without them; reverting the commit is enough. ## Reviewer notes Carried over from [NotRexed/Hookshot#2433](https://github.com/NotRexed/Hookshot/pull/2433) with the move to Longshot: the same change on Longshot's `main`, with its rename applied. Its review and discussion are there (reviewed by Joey-Magnus). - The checks and the game runs above were done on the GitHub version; this branch is the same change with the rename applied (the same files and line counts). Forgejo runs no checks, and they were not run again here. - The change is in `third_party/a64-kit/lift/a64_lift.py` (the lifter), so the `third_party/` box is not ticked. - Since the draft: fused multiply-adds join regions (9f060614, @Jiro131's): they are about half the float ops in Link's movement and collision code, and in Town and Castle one hot file had fallen back to the exact copy in about 55% of runs, which it no longer does. Results Arm doesn't give the same now take the exact copy (1e6b7a2f): the three cases above, found by @Jiro131's `tests/test_fastfp_fma.py` and by the same test once the divide was added to it; check mode never met them in game. Rebased onto GitHub's main, including [NotRexed/Hookshot#2383](https://github.com/NotRexed/Hookshot/pull/2383) (the exact path's single-precision FMA fused on x86-64-v3): the exact copies get it, the fast copies use their own `vfmadd231ss`. - CI on GitHub: Windows part 1 fails on `tests/test_psychov35.py`, from [NotRexed/Hookshot#2481](https://github.com/NotRexed/Hookshot/pull/2481) on main (`scanf` is deprecated under `-Werror` with the runner's MSVC-target clang), not from this PR. - `tests/test_fastfp_fma.py`: each fast op alone in the MXCSR window against the exact body the lifted code falls back to (`recomp_fpe_fma32`, `_div32`, `_add32`, `_sub32`; the vector ops lane by lane, 4 lanes and 2), value and FPSR, FZ off and on, with random operands weighted to the underflow and overflow edges, NaNs, subnormals and cancellations, plus an edge list: 0 mismatches in 2–8M checks per op. It fails if any of the result checks is removed, or the 2-lane ops load four lanes. - `tests/test_fastfp_regions.py`: what may join a region, and a whole region from the real header against plain IEEE results at `-march=x86-64-v3` and `x86-64-v2` (200,000 random runs; a multiply-add rounded once; NaN results, 0 * inf, a denormal operand and a tiny result under FZ take the exact copy with the inputs put back; overflow and divide-by-zero stay fast with FPSR set; the gate closed or `HOS_NO_FASTFP` take the exact copy). It fails if the AVX operands are swapped or the invalid flag stops sending a region to its exact copy. It links libm only off Windows. - How to help test: build this branch and play (anything that behaves differently from `main` is worth a report); or build with `A64_FASTFP=check`, play anywhere, and look in `longshot_log.txt` for `fastfp check: MISMATCH` (there should be none); or compare `HOS_THREAD_TIMES=5` with and without `HOS_NO_FASTFP` on the same exe. **`third_party/`:** this diff changes files under `third_party/`, which Longshot's rules keep as unmodified upstream copies (a new folder with a `PROVENANCE.md` instead). That has to be resolved before this can be ready. ## Issues None. ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [ ] Rebased on current `main`. - [ ] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [ ] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] No game files, dumps, build output or generated files. - [ ] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [ ] Flags table filled in; README / docs/development.md switch reference updated. - [ ] Screenshots for a change that shows on screen. - [ ] A row in `docs/tested-configurations.md` for each measured run. - [ ] `MKWVK_API_VERSION` bumped (`gpu/vk/vk_api.h`'s `MkwVkHost` or `MkwVkRenderer` changed). - [ ] The SPIR-V headers regenerated with glslang (a shader changed). - [x] A game-free test added for the fix, failing on `main` and passing here. - [ ] A check under `tests/` that reads changed source updated in this PR, not weakened. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. - [ ] Docs updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dyst added 4 commits

2026-11-12 23:39:05 +00:00

perf(lift): fast float regions, plain SSE checked once by MXCSR with the exact copy as fallback b411c1f90d

A straight run of single-precision float ops (no label, store, call, branch or system register access; at least 8
adds, subtracts, multiplies, divides or square roots) is lifted twice: a plain SSE copy between one MXCSR flag clear
and one read, and the exact copy. With no invalid, denormal or underflow flag the fast result is Arm's (FTZ on under
FPCR.FZ, ops in Arm's operand order); divide-by-zero, overflow and inexact are or-ed into FPSR; otherwise the registers
the run names are put back and the exact copy runs. On by default; A64_FASTFP=0 off, =hot the hot functions only,
=check both copies every time with mismatches logged; HOS_NO_FASTFP at run time takes the exact copies only.

OoT, Temple of Time (Ryzen 9 3900X): 13,114 regions, 250,040 ops; check mode 0 mismatches in tens of millions of runs;
Havok AI's character step 5.5 -> 4.1 ms of CPU a frame. tests/test_fastfp_regions.py checks the regions game-free.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

fix(test): the fast float regions' C test links libm only off Windows 1d41587297

The Windows runner's clang targets MSVC, which has no m.lib; Windows keeps the math functions in the C runtime.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

perf(lift): fused multiply-add in fast float regions on FMA3 d8b6cbabad

The fast float regions left a64_fpx_fma32_fma32 (FMADD/FMSUB/FNMADD/FNMSUB,
FMLA/FMLS S lanes) as an exact helper call; it is the hottest exact float
helper left in a Kokiri Forest profile. On x86-64-v3, vfmadd231ss rounds once
like Arm and takes its NaN in Arm's order. Two cases differ and now send the
run to its exact copy (an invalid flag raised in the window): any NaN result
(x86 returns 0 * inf + qNaN's NaN with no flag, Arm the default NaN with IOC),
and a result of magnitude 2^-126 (x86 detects tininess after rounding, Arm
before: UFC, and a zero under FZ). Without FMA3 the op stays the exact helper.

tests/test_fastfp_fma.py checks the op in the MXCSR window against
recomp_fpe_fma32 (8M checks, 0 mismatches); it also reports the fast FMUL's
15348 mismatches (the same 2^-126 case, and subnormal x qNaN under FZ).

Assisted-by: Claude Code
Co-Authored-By: Claude Opus 5.5 <[email protected]>

fix(lift): fast float ops keep only results Arm gives the same d3590ecd58

Three cases kept a fast result that differs from Arm's, found by tests/test_fastfp_fma.py (Jiro131's):
- a product, quotient or multiply-add rounded up to exactly 2^-126: x86 detects tininess after rounding, Arm before,
  so Arm sets UFC and, under FZ, gives a zero;
- a NaN beside a subnormal operand: x86 raises no denormal flag, Arm under FZ flushes the subnormal and sets IDC;
- a subnormal over a zero: x86 gives an infinity with divide-by-zero only, Arm under FZ divides 0 by 0 (the default
  NaN, IOC).
Each op now checks its result (any NaN; exactly 2^-126 for the multiply, divide and multiply-add; the divide's
operands for the third case) and raises the invalid flag, so the run takes its exact copy. The 2-lane vector ops load
their upper lanes as zeros, which no longer raise flags of their own (an overflow there set OFC).

tests/test_fastfp_fma.py now holds every fast op, vector ones lane by lane, to the exact bodies: 0 mismatches in 2-8M
checks each; removing any of the checks fails it.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

dyst changed title from ~~perf(lift): fast float regions, plain SSE checked once by MXCSR with the exact copy as fallback~~ to WIP: perf(lift): fast float regions, plain SSE checked once by MXCSR with the exact copy as fallback

2026-11-13 01:14:02 +00:00

dyst commented

2026-11-13 01:14:02 +00:00

Author

First-time contributor

Back to WIP under #48's process: this was carried over before the new template. Its description will be brought to the template and measured on Longshot (main against this PR, at named commits) when it's wanted for review; ask here if you'd like it sooner.

dyst commented

2026-11-13 01:58:28 +00:00

Author

First-time contributor

Description brought to Longshot's PR template (#48). Still WIP: its numbers are from the GitHub version, and it isn't rebased on current main; it gets measured on Longshot (main against this PR, at named commits) before it is marked ready. Note: this diff changes files under third_party/, which Longshot keeps as unmodified upstream copies; that needs resolving before it can be ready.

dyst commented

2026-11-13 02:00:43 +00:00

Author

First-time contributor

Description moved to the template's Testing section and whole checklist (#72): what was tested, what wasn't, and what needs other testers (their test requests to open while this is WIP).

This pull request is marked as a work in progress.

This branch is out-of-date with the base branch

View command line instructions