Skip to content

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
AstSemantics.md Outdated
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.

4 participants