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 在2023年8月21日星期一 UTC+8 14:40:59<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 > > On Thu, Aug 17, 2023 at 4:47 PM ji qiu <qiuji....@gmail.com> wrote: > >> 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 >> >> 在2023年8月16日星期三 UTC+8 18:57:06<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 >>> >>> >>> On Tue, Aug 15, 2023 at 6:16 PM Ji Qiu <qi...@iscas.ac.cn> wrote: >>> >>>> 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 ) >>>> >>>> -- >>>> -- >>>> 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 >>>> >>>> <https://groups.google.com/d/msgid/v8-dev/902db3ea-d56a-4629-ab29-940a381ab872n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> >>> 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. >>> >>> >>> -- >> -- >> 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/da36779d-a11e-4745-9b2e-d1aa44fb482an%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-dev/da36779d-a11e-4745-9b2e-d1aa44fb482an%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > Andreas Haas > > Software Engineer > > ah...@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. > > -- -- v8-dev mailing list v8-dev@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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/274973f1-37c9-4df0-af2e-dab8672f45abn%40googlegroups.com.
