Duplicate deopt

[ltratt]

With yk and yklua compiled in debug mode I can deterministically see this with the bounce benchmark:

$ YKD_OPT=0 RUST_BACKTRACE=1 ~/yklua/src/lua harness.lua bounce 2 1500
Starting bounce benchmark ...
thread '<unnamed>' panicked at ykrt/src/compile/jitc_yk/codegen/x64/deopt.rs:205:17:
assertion `left == right` failed: duplicate deopt with different value
  left: 26907416
 right: 140679686832940
stack backtrace:
   0: rust_begin_unwind
             at /rustc/6d9f6ae36ae1299d6126ba40c15191f7aa3b79d8/library/std/src/panicking.rs:681:5
   1: core::panicking::panic_fmt
             at /rustc/6d9f6ae36ae1299d6126ba40c15191f7aa3b79d8/library/core/src/panicking.rs:75:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /rustc/6d9f6ae36ae1299d6126ba40c15191f7aa3b79d8/library/core/src/panicking.rs:364:5
   4: ykrt::compile::jitc_yk::codegen::x64::deopt::__yk_deopt::{{closure}}
             at /vol/extra/ltratt/yk/ykrt/src/compile/jitc_yk/codegen/x64/deopt.rs:205:17
   5: __yk_deopt
             at /vol/extra/ltratt/yk/ykrt/src/compile/jitc_yk/codegen/x64/deopt.rs:293:21
   6: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 5
zsh: IOT instruction  YKD_OPT=0 RUST_BACKTRACE=1 ~/yklua/src/lua harness.lua bounce 2 1500

It looks like the recently added assert has caught something nasty!

Interestingly, YKD_OPT=0 seems necessary for this bug to manifest deterministically. It's difficult to say for sure why, but it is plausible that is because the optimiser is removing the guard which causes the crash above. In release mode, I do fairly predictably get a crash with YKD_OPT=0 but (a) the crash manifests in a Lua backtrace (b) it's not the same backtrace each time. So probably we should stick to debug mode when fixing this one.

[ltratt]

Here is the most minimal test case I have for bounce.lua for now:

B = {}
do
  function B.B()
    A = {}
    return setmetatable(A, { __index = B })
  end
  function B:A() end
end
A = {}
do
  setmetatable(A, { __index = require("benchmark") })
  function A:benchmark()
    A = 47
    a = {}
    for A = 0, A do
      a[A] = B.B()
      for A = 0, #a do
        A = a[A]
        if A:A() then
        end
      end
    end
  end
  function A:verify_result()
    return 0
  end
end
return A

[ltratt]

So the good news from YK_LOG=4 is that we hit this on the first deopt:

$ YK_LOG=4 YKD_OPT=0 RUST_BACKTRACE=1 ~/yklua/src/lua harness.lua bounce 2 1500
yk-jit-event: start-tracing
yk-jit-event: stop-tracing
yk-jit-event: start-tracing
yk-jit-event: stop-tracing
yk-jit-event: start-tracing
yk-jit-event: stop-tracing
yk-jit-event: enter-jit-code
yk-jit-event: deoptimise
thread '<unnamed>' panicked at ykrt/src/compile/jitc_yk/codegen/x64/deopt.rs:205
:17:
assertion `left == right` failed: duplicate deopt with different value
  left: 14799224
 right: 139623181517612

[ltratt]

Good news: we can find a stand-alone test (without harness.lua et al.) that (a) is much smaller (b) triggers the problem (c) does so on the first execution of the only traced loop. Here's my hand-reduced version:

a = {}
for i = 0, 47 do
  a[i] = {}
  for j = 0, #a do
    x = a[i]
  end
end

To get this to bork we need to turn serialised compilation on:

$ YK_LOG=4 YKD_OPT=0 YKD_SERIALISE_COMPILATION=1 RUST_BACKTRACE=1 ~/yklua/src/lua bork.lua
yk-jit-event: start-tracing
yk-jit-event: stop-tracing
yk-jit-event: enter-jit-code
yk-jit-event: deoptimise
thread '<unnamed>' panicked at ykrt/src/compile/jitc_yk/codegen/x64/deopt.rs:205
:17:
assertion `left == right` failed: duplicate deopt with different value
  left: 14351284
 right: 140279508587308

[ltratt]

This is almost certainly a false bug: loop peeling doesn't jump properly if YKD_OPT=0. I'll fix that and I strongly suspect this particular problem will go away.

[ltratt]

Confirmed that this "bug" is actually the result of a different bug which is fixed in #1523. Closing this one.