-
Notifications
You must be signed in to change notification settings - Fork 695
Permit implementations to return canonical NaNs from arithmetic. #660
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
RISC-V and ARM in "default NaN" mode do not propagate NaN values in arithmetic operations. Instead, they return a "canonical" NaN. IEEE 754 doesn't require NaN propagation; it's merely a "should". In order to ensure that wasm doesn't accidentally over-burden support for the above and other potential future IEEE-754-conforming platforms, this patch changes the NaN rules to permit either behavior.
point arithmetic operator are deterministic under more circumstances than | ||
required by IEEE 754-2008. | ||
- The IEEE 754-2008 recommendation that operations propagate NaN bits from | ||
their operands is permitted but not required. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section details where wasm diverges from IEEE754, so the bullet should be in another list. Also, is there a reference paragraph in IEEE754 for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an area where wasm doesn't "follow" IEEE's recommendation.
I added a reference to the relevant section.
Can we change "nondeterministically" to "implementation-defined"? I'm specifically trying to guarantee that the behavior from one execution to another is the same if the compiler and hardware haven't changed, I think that's a property we can keep. |
I'm not sure that the relationship between one run and another is something we can meaningfully say anything about. I'd encourage you to submit a separate PR to propose specific wording that can be discussed. |
I've now made an attempt at some revised wordings. In general though, while I'm open to suggestions, I want to avoid getting significantly more verbose, because the vast majority of people reading this document won't care about these details, and the remaining people who really need to know precisely what happens here should consult the spec instead anyway (which I'll update once this PR is resolved.) |
Ping :-). Another advantage of this change is that it simplifies implementations that do wish to canonicalize after arithmetic, to avoid propagating unnecessary information or implementation details. |
lgtm |
lgtm. Sorry for the delay, I hadn't seen the reworded version. |
Sounds like lgtms! |
RISC-V and ARM in "default NaN" mode do not propagate NaN values in
arithmetic operations. Instead, they return a "canonical" NaN.
IEEE 754 doesn't require NaN propagation; it's merely a "should".
In order to ensure that wasm doesn't accidentally over-burden support
for the above and other potential future IEEE-754-conforming platforms,
this patch changes the NaN rules to permit either behavior.