yuyang-ok commented on issue #6015:
@afonso360 Looks like The test failure indicates
x64
not implement for small types.
yuyang-ok commented on issue #6015:
@afonso360 I have rewritten to
ISLE
.
fmax_
I can't find a suitable name for this.
Maybe you can review code first.
yuyang-ok edited a comment on issue #6015:
@afonso360 I have rewritten to
ISLE
.
fmax_
I can't find a suitable name.
Maybe you can review code first.
yuyang-ok edited a comment on issue #6015:
@afonso360 I have rewritten to
ISLE
.
fmax_
is That I can't find a suitable name.
Maybe you can review code first.
yuyang-ok edited a comment on issue #6015:
@afonso360 I have rewritten to
ISLE
.
fmax_
is That I can't find a better name.
Maybe you can review code first.
yuyang-ok edited a comment on issue #6015:
@afonso360 I have rewritten to
ISLE
.
fmax_
is That I can't figure out a better name.
Maybe you can review code first.
yuyang-ok commented on issue #6015:
@afonso360 any idea about this failure.
test interpret
test run
target riscv64gc
function %a(f64) -> i16 sext system_v {
block0(v6: f64):
v16 = fcvt_to_sint_sat.i16 v6
return v16
}
; run: %a(-NaN:0x7ffffff666666) == 0
afonso360 commented on issue #6015:
Well, looks like we are not returning 0 for all NaN's. When testing this locally I got
run: %b(-NaN:0x7ffffff666666) == 0, actual: -32768
so it seems like something is going wrong in the NaN checking.<details>
<summary>Disassembly of the test case</summary>
Disassembly of 112 bytes: 0: 97 06 00 00 auipc a3, 0 4: 83 b6 c6 00 ld a3, 0xc(a3) 8: 6f 00 c0 00 j 0xc c: 00 00 00 00 .byte 0x00, 0x00, 0x00, 0x00 10: 00 00 e0 c0 .byte 0x00, 0x00, 0xe0, 0xc0 14: 53 83 06 f2 fmv.d.x ft6, a3 18: d3 15 a3 2a fmax.d fa1, ft6, fa0 1c: 97 0e 00 00 auipc t4, 0 20: 83 be ce 00 ld t4, 0xc(t4) 24: 6f 00 c0 00 j 0xc 28: 00 00 00 00 .byte 0x00, 0x00, 0x00, 0x00 2c: c0 ff df 40 .byte 0xc0, 0xff, 0xdf, 0x40 30: 53 87 0e f2 fmv.d.x fa4, t4 34: d3 88 e5 2a fmin.d fa7, fa1, fa4 38: 53 a8 18 a3 feq.d a6, fa7, fa7 3c: 63 02 08 02 beqz a6, 0x24 40: 53 98 08 c2 fcvt.w.d a6, fa7, rtz 44: 37 8f 00 00 lui t5, 8 48: 93 0f ff ff addi t6, t5, -1 4c: b3 7f f8 01 and t6, a6, t6 50: 13 58 f8 01 srli a6, a6, 0x1f 54: 13 18 f8 00 slli a6, a6, 0xf 58: 33 68 f8 01 or a6, a6, t6 5c: 6f 00 80 00 j 8 60: 13 08 00 00 mv a6, zero 64: 13 15 08 03 slli a0, a6, 0x30 68: 13 55 05 43 srai a0, a0, 0x30 6c: 67 80 00 00 ret
</details>
I haven't looked too close at this, but it looks like we only do the NaN check after the value is clamped, so could that be the reason for the issues?
I also tested building an equivalent test case using LLVM It looks like they do the NaN check on the original input.
yuyang-ok commented on issue #6015:
@afonso360 thanks.
github-actions[bot] commented on issue #6015:
Subscribe to Label Action
cc @cfallin, @fitzgen
<details>
This issue or pull request has been labeled: "cranelift", "isle"Thus the following users have been cc'd because of the following labels:
- cfallin: isle
- fitzgen: isle
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
alexcrichton commented on issue #6015:
Apologies I didn't see this before I ended up making https://github.com/bytecodealliance/wasmtime/pull/7327, but I believe that that PR covers this one so I've annotated that to close this when merged.
Last updated: Nov 22 2024 at 16:03 UTC