Cranelift aarch64: fix interrupt tests
Categories
(Core :: JavaScript: WebAssembly, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox79 | --- | fixed |
People
(Reporter: bbouvier, Assigned: bbouvier)
References
Details
Attachments
(3 files)
Now that multi-value has landed, we can isolate the tests failing timeouts.
Upon investigation, I looked at the very simple timeout/1.js test. It's just a function with an infinite loop.
In CLIR:
[2020-06-12T09:56:05Z DEBUG baldrdash::compile] Optimized wasm function IR: function u0:0(i64 vmctx) baldrdash_system_v {
gv0 = vmctx
gv1 = iadd_imm.i64 gv0, 56
block0(v0: i64):
@0022 v3 = iconst.i64 56
@0022 v1 = iadd v0, v3
@0022 jump block2
block2:
@0022 v2 = load.i32 notrap aligned v1
@0022 brz v2, block5
@0022 jump block4
block4:
@0022 trap interrupt
block5:
@0024 jump block2
}
But the generated code is:
0x1306ed293000 d10083ff sub sp, sp, #0x20 (32)
0x1306ed293004 f9000ffe str x30, [sp, #24]
0x1306ed293008 f90007f7 str x23, [sp, #8]
0x1306ed29300c f90003fd str x29, [sp]
0x1306ed293010 910003fd mov x29, sp
0x1306ed293014 d503201f nop
0x1306ed293018 d503201f nop
0x1306ed29301c d503201f nop
0x1306ed293020 7100055f cmp w10, #0x1 (1)
0x1306ed293024 54000180 b.eq #+0x30 (addr 0x1306ed293054)
0x1306ed293028 d4a00000 unimplemented (Exception)
0x1306ed29302c 14000003 b #+0xc (addr 0x1306ed293038)
0x1306ed293030 ffff0001 unallocated (Unallocated)
0x1306ed293034 14000008 b #+0x20 (addr 0x1306ed293054)
0x1306ed293038 d503201f nop
0x1306ed29303c d503201f nop
0x1306ed293040 d10083ff sub sp, sp, #0x20 (32)
0x1306ed293044 f9000ffe str x30, [sp, #24]
0x1306ed293048 f90007f7 str x23, [sp, #8]
0x1306ed29304c f90003fd str x29, [sp]
0x1306ed293050 910003fd mov x29, sp
0x1306ed293054 9100e2e0 add x0, x23, #0x38 (56)
0x1306ed293058 b8400001 ldur w1, [x0]
0x1306ed29305c 2a0103e1 mov w1, w1
0x1306ed293060 b4ffffc1 cbz x1, #-0x8 (addr 0x1306ed293058)
0x1306ed293064 d4a00000 unimplemented (Exception) <--- Insert backedge after this instruction
0x1306ed293068 f94003fd ldr x29, [sp]
0x1306ed29306c f94007f7 ldr x23, [sp, #8]
0x1306ed293070 f9400ffe ldr x30, [sp, #24]
0x1306ed293074 910083ff add sp, sp, #0x20 (32)
0x1306ed293078 d65f03c0 ret
There should be a jump back to the loop's header after the trap instruction (d4a00000).
There's a CLIF IR instruction that's meant to use for resumable traps, and we don't use it. So not sure why it works on the old x86 backend; maybe there's no fallthrough optimizations there?
In any case, we need to have this jump after the trap instruction. Will investigate further.
Assignee | ||
Comment 1•4 years ago
|
||
Using the trapnz instruction was incorrect, because traps can't be resumed in
theory, so the previous x86 backend was only working because it would not
remove the jump after this trap instruction. Make it more correct by not lying
to Cranelift and use a conditional resumable trap instead.
Will need a Cranelift bump as well.
Assignee | ||
Comment 2•4 years ago
|
||
This solves a remaining failure in wasm/spec/spec/left-to-right.wast.js, where
the whole function's body is optimized away.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Comment 5•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c0f29bcb0174
https://hg.mozilla.org/mozilla-central/rev/3e29a8890281
https://hg.mozilla.org/mozilla-central/rev/4b8bb44f41c1
Description
•