Fix #5208: Introduce raw floating point bit manipulation. #5209
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
53d2535 to
8d07f6f
Compare
gzm0
approved these changes
Jul 14, 2025
| valueInt | ||
| else if (isNaNBitPattern(bits)) | ||
| Long.hashCode(0x7ff8000000000000L) |
There was a problem hiding this comment.
Make the canonicalized NaN bit pattern a constant for readability?
| @inline def floatToIntBits(value: scala.Float): scala.Int = { | ||
| val rawBits = floatToRawIntBits(value) | ||
| if (isNaNBitPattern(rawBits)) | ||
| 0x7fc00000 |
There was a problem hiding this comment.
Same: Make this a compile time constant for readability?
We repurpose the previous opcodes to mean the raw variants. They do not provide any guarantee for the NaN bit patterns (other than being one of the NaN patterns, obviously). We now implement the canonicalizing variants in user-space on top of the raw variants. On Wasm, we had to do that anyway, except the "user-space" was in the function emitter. On JavaScript, despite the spec "suggesting" that NaN's be canonicalized, real-world engines do not canonicalize all NaN's. Doing it in user-space is the only reliable way to guarantee our spec. --- We replace usages of the canonicalizing variants by raw variants in the low-level javalib methods where we can. Either they are in code paths where NaN's have been excluded, or where it does not actually matter what bit pattern we receive for NaN's. This allows not to regress on performance and code size for some low-level methods. Unfortunately, `Double.hashCode` does require one more branch, but that is inevitable to guarantee the correct semantics. `ByteBuffer` methods `putFloat` and `putDouble` do not specify the bit patterns of `NaN`s, and experimentally, I was able to observe non-canonical bit patterns on the JVM. So in that case, we also use the raw variants, which is consistent with using the `DataView` methods in `TypedArray`-backed byte buffers.
8d07f6f to
47498f2
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.
We repurpose the previous opcodes to mean the raw variants. They do not provide any guarantee for the NaN bit patterns (other than being one of the NaN patterns, obviously).
We now implement the canonicalizing variants in user-space on top of the raw variants.
On Wasm, we had to do that anyway, except the "user-space" was in the function emitter. On JavaScript, despite the spec "suggesting" that NaN's be canonicalized, real-world engines do not canonicalize all NaN's. Doing it in user-space is the only reliable way to guarantee our spec.
We replace usages of the canonicalizing variants by raw variants in the low-level javalib methods where we can. Either they are in code paths where NaN's have been excluded, or where it does not actually matter what bit pattern we receive for NaN's. This allows not to regress on performance and code size for some low-level methods. Unfortunately,
Double.hashCodedoes require one more branch, but that is inevitable to guarantee the correct semantics.ByteBuffermethodsputFloatandputDoubledo not specify the bit patterns ofNaNs, and experimentally, I was able to observe non-canonical bit patterns on the JVM. So in that case, we also use the raw variants, which is consistent with using theDataViewmethods inTypedArray-backed byte buffers.