Add SIMD emulation of mul_add_precise for f64 on SSE4.2 - #324
Open
Shnatsel wants to merge 6 commits into
Open
Conversation
awxkee
approved these changes
Aug 10, 2026
awxkee
left a comment
awxkee
left a comment
There was a problem hiding this comment.
LGTM
Dekker product with Veltkamp's split is no doubts impossible for edge cases which the paper covers only with a blanket "provided that underflow and overflow do not occur", and instead it use fast2mult using FMA in annex to compute FMA, what is a little bit ironic. Since values that are impossible to split are gated here, everything else seems correct to me.
Contributor
Author
|
Thanks a lot! |
Shnatsel
changed the title
mul_add_precise for SSE4.2mul_add_precise for f64 on SSE4.2
…es, but only 0.7x on subnormal/huge values
The kernel now magnitude-sorts both error-free additions and uses Fast2Sum, shortening their dependency chains. The correction predicate also omits redundant exponent classification under the existing safe-range proof. Also tried and rejected an exponent-bit correction kernel and a one-blend Fast2Sum formulation because they regressed the real benchmark. Here's what llvm-mca thinks: | CPU model | Original throughput | Optimized throughput | Modeled total cycles | |---|---:|---:|---:| | Zen 4 | 11.5 → 9.5 | 17% better | 41.1 → 36.1 | | Nehalem | 24 → 20 | 17% better | 53.1 → 49.1 | | Tremont | 47 → 37 | 21% better | 108.0 → 87.1 |
…ance by 25% in time and 33% in throughput on Zen4 benchmarks and showing llmv-mca improvements across the board
Shnatsel
force-pushed
the
mul_add_precise_f64
branch
from
August 12, 2026 15:06
ab19a76 to
9e4a6cf
Compare
Shnatsel
marked this pull request as ready for review
August 12, 2026 15:06
Contributor
Author
|
Now that #323 is merged, I've rebased it on main and this is now ready for review |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The implementation is based on a 2025 paper by Graillat and Muller, Emulation of the FMA and the correctly-rounded sum of three numbers in rounding-to-nearest floating-point arithmetic. Integrating cutting edge research here!
To the best of my knowledge this doesn't fix any libm or musl bugs, so this isn't necessary for correctness, it's just an optimization.
This is upwards of 3x faster than scalar on normal values; huge values and subnormals fall back to scalar and only get about 0.7x the usual scalar performance. It's still worth it because subnormals are rare and slow even in hardware.
@awxkee I'd appreciate it if you could take a look