Skip to content

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

Merged
merged 4 commits into from
Apr 28, 2016

Conversation

sunfishcode
Copy link
Member

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.

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.
@sunfishcode sunfishcode mentioned this pull request Apr 19, 2016
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.
Copy link
Member

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?

Copy link
Member Author

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.

@jfbastien
Copy link
Member

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.

@sunfishcode
Copy link
Member Author

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.

@sunfishcode
Copy link
Member Author

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.)

@sunfishcode
Copy link
Member Author

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.

@titzer
Copy link

titzer commented Apr 26, 2016

lgtm

@jfbastien
Copy link
Member

lgtm. Sorry for the delay, I hadn't seen the reworded version.

@sunfishcode
Copy link
Member Author

Sounds like lgtms!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants