Use 128-bit Widening Multiply on More Platforms #62
Conversation
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
scottmcm
reviewed
Jul 7, 2025
src/lib.rs
Outdated
Comment on lines
237
to
245
| #[cfg(not(any( | ||
| all( | ||
| target_pointer_width = "64", | ||
| not(any(target_arch = "sparc64", target_arch = "wasm64")), | ||
| ), | ||
| target_arch = "aarch64", | ||
| target_arch = "x86_64", | ||
| all(target_family = "wasm", target_feature = "wide-arithmetic"), | ||
| )))] |
There was a problem hiding this comment.
YMMV: since both arms should compile fine on both, maybe use cfg! instead of #[cfg]? Then it could be an else here and remove a bunch of duplication, while still optimizing out the unused part. (if const { false } is optimized even in debug mode.)
There was a problem hiding this comment.
Alright, I changed it to a simple if.
The 128-bit widening multiplication was previously gated by simply checking the target pointer width. This works as a simple heuristic, but a better heuristic can be used: 1. Most 64-bit architectures except SPARC64 and Wasm64 support the 128-bit widening multiplication, so it shouldn't be used on those two architectures. 2. The target pointer width doesn't always indicate that we are dealing with a 64-bit architecture, as there are ABIs that reduce the pointer width, especially on AArch64 and x86-64. 3. WebAssembly (regardless of pointer width) supports 64-bit to 128-bit widening multiplication with the `wide-arithmetic` proposal. The `wide-arithmetic` proposal is available since the LLVM 20 update and works perfectly for this use case as can be seen here: https://rust.godbolt.org/z/9jY7fxqxK Using `wasmtime explore`, we can see it compiles down to the ideal instructions on x86-64: ```nasm mulx rax, rdx, r10 xor rax, rdx ``` Based on the same change in [`foldhash`](orlp/foldhash#17).
CryZe
force-pushed
the
128-bit-on-more-platforms
branch
from
146ff74 to
6849c16
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 128-bit widening multiplication was previously gated by simply checking the target pointer width. This works as a simple heuristic, but a better heuristic can be used:
wide-arithmeticproposal.The
wide-arithmeticproposal is available since the LLVM 20 update and works perfectly for this use case as can be seen here:https://rust.godbolt.org/z/9jY7fxqxK
Using
wasmtime explore, we can see it compiles down to the ideal instructions on x86-64:Based on the same change in
foldhash.