Is there any rule for NaN propagation in JSToWasmWrapper?

[Ji Qiu]

RISC-V has not implemented generic js-to-wasm wrapper at the moment. So it still uses the stub function JSToWasmWrapper.

The wasm value types are converted to smi or HeapNumbers

(the call path is BuildCallAndReturn->ToJS).

When a F32 value is returned in a wasm function, the wrapper may convert the F32 to a proper tagged value, if it can't convert to a smi value, it would be convert to a object containing double value and the tagged pointer of the object would be seen from JS side.(by BuildChangeFloat32ToNumber Node)

My question is that when a NaN F32 is returned, is there any rule or specification for the propagation of NaN?

Newbie for Wasm. Sorry If I missed any common documentation for this part :) Thx!

Background: The bug for filed for RISCV ( https://bugs.chromium.org/p/v8/issues/detail?id=14269 ) 

[Clemens Backes]

Hi Ji,

as the NaN pattern is not observable from the JS side, no specification says anything about the bit representation of a Wasm NaN when converted to a JS value. What other platforms do is to just keep the value as it is, and store it in a HeapNumber. We don't *have to* do that, we could also use a canonical NaN value on the JS side, but then we would have to explicitly canonicalize on the boundary of Wasm and JS.

The failing cctest in https://crbug.com/v8/14269 tests that NaN values are received in JS unmodified, so it tests what we do on other platforms. That's not mandated by the Wasm specification though, so we could decide to canonicalize NaN values and relax the test to allow for that.

Would it be easier for RISC-V to canonicalize on the boundary? Or does it already do that, and that's why the tests are failing?

-Clemens

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/902db3ea-d56a-4629-ab29-940a381ab872n%40googlegroups.com.

--

Clemens Backes

Software Engineer

clem...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian   

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[ji qiu]

Hi Clemens,

I appreciate your detailed explanation.  

For RISC-V, it's a bit complex to keep the value as it is like other platforms do. Its standard specifies the propagation of any type of NaN to a positive canonical NaN ( https://github.com/riscv/riscv-isa-manual/blob/main/src/f-st-ext.adoc#nan-generation-and-propagation). Some of the floating point instructions keep the NaN payload bits as it is, such as float load and store, moving between GPR and FPR.

However, other ISAs provide options to propagate NaN with all payloads or default canonical NaN( positive canonical NaN).  For example, ARM64 in its default mode (fpcr with DN bit equals 0),  the payload is propagated by hardware automatically. In RISC-V, canonicalizing on the boundary might bring a long assemble sequence to the code gen of CvtDS and CvtSD arch opcodes. But it's perhaps rare to meet such a case in real situations.

So if there is no specification that says anything about the bit representation of a Wasm NaN when converted to a JS value, I suggest just leaving the test case skip for RISC-V unless it's necessary.

BRs,

Ji

[Andreas Haas]

I wonder if we should adjust the test, so that it does not return the f32 value but write it to memory instead. The test should check the kExprF32ReinterpretI32 instruction in wasm, not the heap number creation in JavaScript.

Cheers, Andreas

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/da36779d-a11e-4745-9b2e-d1aa44fb482an%40googlegroups.com.

--

Andreas Haas

Software Engineer

ah...@google.com

[ji qiu]

It sounds reasonable. Andreas. 

But before this adjustment landed, would RISC-V skip this case for the described reason? 

Perhaps this CL (https://chromium-review.googlesource.com/c/v8/v8/+/4781027) can be landed first,  could you pls take a look at the cctest.status file? Thanks!

BRs,

Ji