RISC-V and NaNs

[sunfishcode]

RISC-V is a new ISA with interesting potential. Overall, it looks like it should support WebAssembly very well. The following are two concerns regarding its handling of NaNs:

• RISC-V defines its hardware-generated NaN values as all-ones. This differs from ARM, MIPS (in IEEE 754-2008 mode, which wasm already requires), Power, and x86, and could significantly complicate NaN boxing on wasm. I've posted to the RISC-V isa-dev forum asking whether it's feasible to change RISC-V to be compatible, as a first step.
• IEEE 754-2008 makes exemptions to its usual NaN propagation rules for min, max, and conversions. RISC-V takes advantage of these exemptions. The current wasm design does not currently have these exemptions, but they are in IEEE 754-2008, and could be added to wasm without significant practical cost, so we should consider them.

[sunfishcode]

The reply on the RISC-V list is that they're changing the canonical NaN encoding to have an all-zeros payload. That takes care of the first point above :-).

For the second point, there are two parts:

First, wasm does not currently have operators corresponding to IEEE 754-2008's minNum and maxNum, so these aren't an immediate concern. However, there is a good chance it will in the future, at which point we'll need to implement special rules for them. It seems that maxNum(2.0, qNaN) is 2.0, while maxNum(2.0, sNaN) is qNaN, which is non-obvious.

And second, loosening the semantics for conversions of NaNs is indeed sounding like a good idea; it's supported IEEE 754-2008, it'll help RISC-V, and it may help other architectures as well.

[jfbastien]

Are the exemptions only related to S / Q, or do they allow dropping the payload as well? It would be nice if NaN boxing still worked in some form.

[pizlonator]

On Apr 12, 2016, at 10:41 AM, Dan Gohman notifications@github.com wrote:

The reply on the RISC-V list is that they're changing the canonical NaN encoding to have an all-zeros payload. That takes care of the first point above :-).

That's great!
For the second point, there are two parts:

First, wasm does not currently have operators corresponding to IEEE 754-2008's minNum and maxNum, so these aren't an immediate concern. However, there is a good chance it will in the future, at which point we'll need to implement special rules for them. It seems that maxNum(2.0, qNaN) is 2.0, while maxNum(2.0, sNaN) is qNaN, which is non-obvious.

Have we reached consensus that RISC-V is an architecture that we should accommodate?
And second, loosening the semantics for conversions of NaNs is indeed sounding like a good idea; it's supported IEEE 754-2008, it'll help RISC-V, and it may help other architectures as well.

I'm not sure about this. Tighter semantics is a good thing. I don't think that the existence of an architecture that has looser semantics is sufficient to warrant loosening the spec. I also don't think that we need to be as permissive as 754. Just because 754 allows implementations to fib doesn't mean we have to, particularly if the available mainstream implementations already agree to something tighter.

But let's even assume that we should accommodate RISC-V. If that's the case then do we know that min/max are essential for perf and that an implementation on RISC-V that does extra work to propagate NaNs "our way" would be too expensive?

-Filip

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[sunfishcode]

Have we reached consensus that RISC-V is an architecture that we should accommodate?

No; I don't see it as a requirement. However, it would be nice if it's not complicated and doesn't interfere with our other goals. Right now, it looks promising.

I'm not sure about this. Tighter semantics is a good thing. I don't think that the existence of an architecture that has looser semantics is sufficient to warrant loosening the spec. I also don't think that we need to be as permissive as 754. Just because 754 allows implementations to fib doesn't mean we have to, particularly if the available mainstream implementations already agree to something tighter.

I basically agree; I don't expect to propose 754's exact rule; I expect to propose a more specific form that still allows us to support NaN boxing.

We don't have consensus to make NaN bits deterministic. Consequently, we're left with the following criteria:

• we want wasm itself to be IEEE 754 conforming (for the parts it implements)
• we want to support reasonable and efficient NaN boxing on top of wasm
• we don't want to require extra instructions to canonicalize NaNs on important platforms

I believe it's possible to accomodate RISC-V in this area without compromising any of these. Are there other criteria we should be considering here?

But let's even assume that we should accommodate RISC-V. If that's the case then do we know that min/max are essential for perf and that an implementation on RISC-V that does extra work to propagate NaNs "our way" would be too expensive?

RISC-V's min/max behavior was surprising to me at the beginning of this issue, but I've since learned that it's doing exactly what IEEE 754-2008 specifies for minNum/maxNum. Consequently, this isn't a RISC-V-specific issue.

[pizlonator]

On Apr 12, 2016, at 12:10 PM, Dan Gohman notifications@github.com wrote:

Have we reached consensus that RISC-V is an architecture that we should accommodate?

No; I don't see it as a requirement. However, it would be nice if it's not complicated and doesn't interfere with our other goals. Right now, it looks promising.

I'm not sure about this. Tighter semantics is a good thing. I don't think that the existence of an architecture that has looser semantics is sufficient to warrant loosening the spec. I also don't think that we need to be as permissive as 754. Just because 754 allows implementations to fib doesn't mean we have to, particularly if the available mainstream implementations already agree to something tighter.

I basically agree; I don't expect to propose 754's exact rule; I expect to propose a more specific form that still allows us to support NaN boxing.

We don't have consensus to make NaN bits deterministic. Consequently, we're left with the following criteria:

we want wasm itself to be IEEE 754 conforming (for the parts it implements)
we want to support reasonable and efficient NaN boxing on top of wasm
we don't want to require extra instructions to canonicalize NaNs on important platforms
I believe it's possible to accomodate RISC-V in this area without compromising any of these. Are there other criteria we should be considering here?

These are good criteria.

I was using this criterion: be as deterministic as existing implementations will permit.

What do you think of this criterion?

But let's even assume that we should accommodate RISC-V. If that's the case then do we know that min/max are essential for perf and that an implementation on RISC-V that does extra work to propagate NaNs "our way" would be too expensive?

RISC-V's min/max behavior was surprising to me at the beginning of this issue, but I've since learned that it's doing exactly what IEEE 754-2008 specifies for minNum/maxNum. Consequently, this isn't a RISC-V-specific issue.

The fact that it's surprising makes me wish we did something less surprising.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[sunfishcode]

I was using this criterion: be as deterministic as existing implementations will permit.

What do you think of this criterion?

I do like it, in general, and it is how wasm's current NaN rules were designed. However, in the specific case in this issue (the NaN payload after a floating-point conversion with an input NaN with a non-zero payload), it's difficult to see a practical advantage. However, I'll collect more information before making any actual proposals.

The fact that it's surprising makes me wish we did something less surprising.

We don't actually have minNum or maxNum in the wasm spec right now, so it's not actually a problem yet. They are present in IEEE 754 etc., and in ARM hardware (vminnm/vmaxnm) etc., so there could be pressure to add them in the future. The main conclusion here for now is just: we should be careful.

[sunfishcode]

Further discussions indicate that RISC-V does not plan to implement NaN propagation for any operators. They cite increased hardware cost and a lack of use cases.

While making WebAssembly more deterministic is nice in theory, it's always going to be somewhat nondeterministic in the area of NaN bits due to differences in popular hardware, and it's not clear what we actually gain by merely making it slightly-less-nondeterministic. And, it's not clear that we actually want to require present and future hardware designers to pay extra costs for a feature with no other motivating use cases.

Consequently, I am proposing #660, which permits implementations to optionally return canonical NaNs instead of performing propagation. The typical NaN boxing scheme still works. We still have IEEE 754 conformance. This will enable more platforms to avoid extra canonicalization instructions.