Skip to content
This repository was archived by the owner on Jun 26, 2020. It is now read-only.

Document NaN propagation semantics #20

Closed
stoklund opened this issue Nov 2, 2016 · 3 comments · Fixed by #173
Closed

Document NaN propagation semantics #20

stoklund opened this issue Nov 2, 2016 · 3 comments · Fixed by #173

Comments

@stoklund
Copy link
Contributor

stoklund commented Nov 2, 2016

The language reference is not so clear on what happens when floating point arithmetic instructions produce a NaN. We should specify that.

  • Can instructions return a signaling NaN or only quiet NaNs?
  • When propagating a NaN input, can the payload bits change?

The specification should be tight enough that WebAssembly semantics are simple to represent, and loose enough that we don't need lots of NaN adjustment code emitted for fadd on common targets.

Copying the WebAssembly semantics is probably a good choice.

@serprex
Copy link

serprex commented Dec 25, 2016

@sunfishcode
Copy link
Member

Some background questions:

  • Can Cretonne depend on the IEEE 754-2008-recommended encoding for signaling NaN? This would simplify some things in the NaN rules, with the only practical downside being incompatibility with older (though still in use) MIPS CPUs. For reference, WebAssembly has this dependency, though Rust doesn't.

  • Should Cretonne keep the non-associative minnum/maxnum operators?

@stoklund
Copy link
Contributor Author

  • I think we should follow WebAssembly on NaN representations for now. We can revisit if old MIPS chips become relevant for us.
  • I would be OK with removing fmaxnum and fminnum. We should add a note to the remaining fmin and fmax to make it clear that they are not the functions from IEEE 754-2008.

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

Successfully merging a pull request may close this issue.

3 participants