components: Use f{32,64} as wrapped type of Val::Float{32,64}
#5480
Comments
|
For the record, this floats-as-bits representation was copied from the equivalent API for modules: wasmtime/crates/wasmtime/src/values.rs Lines 22 to 32 in b47e644 |
|
We do this in Cranelift too. I don't know if it's for the same reason that Wasmtime's API works this way, but Cranelift's reason was discussed in #2251. In short, Rust doesn't make any guarantees about the bit-representation of NaN values being preserved in floating-point types. So if you care about that, you need to keep the raw bits in an integer type until the time when you want to do actual floating-point operations on them. |
|
@jameysharp Thanks for that context. The component model requires canonicalization of NaNs so it seems like it makes sense to diverge from the copied API here. |
|
I agree that while this matches the core wasm API it can be different for hte ocmponent model due to all NaN's being canonicalized. @lann would you be up for PR-ing this change? |
alexcrichton
added
the
wasm-proposal:component-model
|
Sure, I can take it. |
…2,64}`
The definitions of `wasmtime::component::Val::Float{32,64}` mirrored
`wasmtime::Val::F{32,64}` in using `u{32,64}` as their wrapped types.
This is necessary for the core wasm `f32`/`f64` types because Rust's
floating-point types don't guarantee the preservation of NaN bit
representations. The component model `float32`/`float64` on the other
hand require NaN canonicalization, so we can use the more natural
Rust `f{32,64}` instead.
Closes bytecodealliance#5480
…2,64}`
The definitions of `wasmtime::component::Val::Float{32,64}` mirrored
`wasmtime::Val::F{32,64}` in using `u{32,64}` as their wrapped types.
This is necessary for the core wasm `f32`/`f64` types because Rust's
floating-point types don't guarantee the preservation of NaN bit
representations. The component model `float32`/`float64` on the other
hand require NaN canonicalization, so we can use the more natural
Rust `f{32,64}` instead.
Closes bytecodealliance#5480
The definitions of `wasmtime::component::Val::Float{32,64}` mirrored
`wasmtime::Val::F{32,64}` in using `u{32,64}` as their wrapped types.
This is necessary for the core wasm `f32`/`f64` types because Rust's
floating-point types don't guarantee the preservation of NaN bit
representations. The component model `float32`/`float64` on the other
hand require NaN canonicalization, so we can use the more natural
Rust `f{32,64}` instead.
Closes bytecodealliance#5480
The definitions of `wasmtime::component::Val::Float{32,64}` mirrored
`wasmtime::Val::F{32,64}` by using integers as their wrapped types,
storing the bit representation of their floating point values.
This was necessary for the core Wasm `f32`/`f64` types because Rust
floats don't have guaranteed NaN bit representations.
The component model `float32`/`float64` types require NaN
canonicalization, so we can use normal Rust `f{32,64}` instead.
Closes bytecodealliance#5480
The definitions of `wasmtime::component::Val::Float{32,64}` mirrored
`wasmtime::Val::F{32,64}` by using integers as their wrapped types,
storing the bit representation of their floating point values.
This was necessary for the core Wasm `f32`/`f64` types because Rust
floats don't have guaranteed NaN bit representations.
The component model `float32`/`float64` types require NaN
canonicalization, so we can use normal Rust `f{32,64}` instead.
Closes #5480
Currently the
wasmtime::component::Val::Float32and::Float64variants wrapu32andu64values:wasmtime/crates/wasmtime/src/component/values.rs
Lines 502 to 503 in b47e644
I suspect this is just an oversight as typed functions do use
f32/f64. I'm happy to make this update if it makes sense.The text was updated successfully, but these errors were encountered: