Skip to content

ppc64 JIT: fix float <=/>= with NaN operands - #413

Closed
runlevel5 wants to merge 1 commit into
ec-:mainfrom
runlevel5:ppc64-qvm-fcmp-nan
Closed

ppc64 JIT: fix float <=/>= with NaN operands#413
runlevel5 wants to merge 1 commit into
ec-:mainfrom
runlevel5:ppc64-qvm-fcmp-nan

Conversation

@runlevel5

Copy link
Copy Markdown
Contributor

The PPC64 JIT compiled OP_LEF/OP_GEF as a single CR0 test, but fcmpu only sets the SO bit on a NaN operand, so NaN <= x and NaN >= x wrongly took the branch. Now folds the unordered bit in via cror so it matches the interpreter and the aarch64 JIT (both false). Other float compares and the integer paths are unchanged. Verified with a JIT-vs-interpreter diff: NaN <= 1.0 returned 1 before, 0 after.

OP_LEF/OP_GEF mapped to a single CR0 test (branch if !GT / !LT). PPC
FCMPU sets only CR0[SO] when an operand is NaN, leaving LT/GT/EQ clear,
so those conditions wrongly took the branch on unordered operands -
diverging from the interpreter and aarch64 (where NaN <= / >= is false).

Fold the unordered bit into the tested bit via cror before the branch
(GT |= SO for <=, LT |= SO for >=) so a NaN operand does not branch.
Ordered comparisons and the other four float compares are unaffected;
the integer LE/GE paths are untouched.

Verified with a differential harness (JIT vs interpreter): NaN <= / >= 1.0
returned 1 on the JIT before and 0 after, matching the interpreter.
@runlevel5 runlevel5 closed this Jun 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant