Skip to content

Conversation

theduke
Copy link
Contributor

@theduke theduke commented Oct 10, 2025

Replaces f64 min/max emulation with the regular LLVM intrinsics.

The emulation was previously added because of codegen issues with LLVM 11,
but that does not seem to be an issue with LLVM 18 anymore

Closes #5771

This change drastically improves the performance of the test case in issue #5771 .

Before:

1.801928 +- 0.000585 seconds time elapsed ( +- 0.03% )

After:

0.0033426 +- 0.0000986 seconds time elapsed ( +- 2.95% )

NOTE: Still need to fix preserving nan canonicalization!

Replaces f64 min/max emulation.

The emulation was previously added because of codegen issues with LLVM 11,
but that does not seem to be an issue with LLVM 18 anymore.

- add llvm.minimum.* / llvm.maximum.* intrinsics to the LLVM translator
- lower scalar and vector f{32,64}.{min,max} directly to those intrinsics
- drop the legacy constrained fcmp/select emulation that was blocking native lowering
- rely on the existing canonicalise-nans path so Wasm’s NaN semantics stay intact
- restores native LLVM min/max codegen and removes the observed f64.min slowdown
@theduke
Copy link
Contributor Author

theduke commented Oct 10, 2025

The initial fix removed canonicalization.

With those added back, we are almost as slow as before, even when using the intrinsics.

So the real culprit seems to be the canonicalization system.
Will need to investigate if there are optimisation possibilities there.

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.

The f64.min instruction causes a performance degradation in wasmer's LLVM backend

1 participant