For floating point operations, allow inputs to be arbitrary, including SNaNs. #883
Conversation
…g SNaNs. Instead of ensuring outputs are arithmetic NaNs on every function, we tag them as pending such a check, so that a sequence of computation can have a single canonicalization step at the end. There's an extra wriggle for SIMD. The Wasm type system only indicates them as V128, so it's possible that we might do computations as F32x4Add, I8x16Add, F64x2Add in a row with no other computations in between. Thus, most SIMD functions apply pending canonicalizations to their inputs, even integer SIMD operations.
|
@syrusakbary I'd appreciate if you could benchmark with this PR, please! |
|
bors try |
tryBuild succeeded
|
|
I ran some benchmarks with particle-repel:
The speedup with non-SIMD is what I expected. I know we have to handle SIMD differently, and that it can put canonicalizations where we didn't use to have them sometimes, but I was not expecting a slowdown compared to our current approach. It looks like wasi-sdk-5 doesn't emit a SIMD FDiv operation, but instead emits individual FDivs. At master, we got lucky with the LLVM autovectorizer reassembling it into a SIMD operation, but with this branch, we got unlucky and one of the fdivs moved into a different basic block. Overall we emit fewer instructions, even for the SIMD case, with this patch. That usually translates into better performance, but in this particular benchmark, the fdiv performance dominates. |
|
Good to merge once we have the changes integrated in the Changelog |
|
bors r+ |
883: For floating point operations, allow inputs to be arbitrary, including SNaNs. r=nlewycky a=nlewycky # Description For floating point operations, allow inputs to be arbitrary, including SNaNs. Instead of ensuring inputs are canonical NaNs on every operation, we tag outputs as pending such a canonicalization check, so that a sequence of computations can have a single canonicalization step at the end. There's an extra wriggle for SIMD. The Wasm type system only indicates them as V128, so it's possible that we might do computations as F32x4Add, I8x16Add, F64x2Add in a row with no other computations in between. Since a canonicalization may change the bit patterns in a way that transforms one non-NaN to another non-NaN in the next subsequent instructions interpretation, most SIMD functions apply pending canonicalizations to their inputs, even the integer SIMD operations. # Review - [x] Add a short description of the the change to the CHANGELOG.md file Co-authored-by: Nick Lewycky <nick@wasmer.io> Co-authored-by: nlewycky <nick@wasmer.io> Co-authored-by: Syrus Akbary <me@syrusakbary.com>
Build succeeded
|
Description
For floating point operations, allow inputs to be arbitrary, including SNaNs.
Instead of ensuring inputs are canonical NaNs on every operation, we tag outputs as pending such a canonicalization check, so that a sequence of computations can have a single canonicalization step at the end.
There's an extra wriggle for SIMD. The Wasm type system only indicates them as V128, so it's possible that we might do computations as F32x4Add, I8x16Add, F64x2Add in a row with no other computations in between. Since a canonicalization may change the bit patterns in a way that transforms one non-NaN to another non-NaN in the next subsequent instructions interpretation, most SIMD functions apply pending canonicalizations to their inputs, even the integer SIMD operations.
Review