Inlining breaks asyncify

Start by reproducing the issue with the shown input.wat using bin/wasm-opt -O2 --asyncify -S, then run output.wat with bin/wasm-shell and compare the printed sequence. Inspect commit 1a6efdb4233a077bc6e5e8a340baf5672bb5bced and the asyncify/inlining behavior it changed. Done means the transformed module preserves the expected 1, 2, 1, 3, 3 output.

While reading @kripken 's post on asyncify, I gave the test case shown a go:

  (memory 1 1)
  (import "spectest" "print" (func $print (param i32)))
  (import "asyncify" "start_unwind" (func $asyncify_start_unwind (param i32)))
  (import "asyncify" "stop_unwind" (func $asyncify_stop_unwind))
  (import "asyncify" "start_rewind" (func $asyncify_start_rewind (param i32)))
  (import "asyncify" "stop_rewind" (func $asyncify_stop_rewind))
  (global $sleeping (mut i32) (i32.const 0))
  (start $runtime)
  (func $main
    (call $print (i32.const 1))
    (call $sleep)
    (call $print (i32.const 3))
  )
  (func $sleep
    (if
      (i32.eqz (global.get $sleeping))
      (block
        ;; Start to sleep.
        (global.set $sleeping (i32.const 1))
        (i32.store (i32.const 16) (i32.const 24))
        (i32.store (i32.const 20) (i32.const 1024))
        (call $asyncify_start_unwind (i32.const 16))
      )
      (block
        ;; Resume after sleep.
        (call $asyncify_stop_rewind)
        (global.set $sleeping (i32.const 0))
      )
    )
  )
  (func $runtime
    ;; Call main the first time, let the stack unwind.
    (call $main)
    (call $asyncify_stop_unwind)
    ;; We could do anything we want around here while
    ;; the code is paused!
    (call $print (i32.const 2))
    ;; Set the rewind in motion.
    (call $asyncify_start_rewind (i32.const 16))
    (call $main)
  )
)

I was quite surprised that after:

$ bin/wasm-opt -o output.wat input.wat -O2 --asyncify -S
$ bin/wasm-shell output.wat                             
BUILDING MODULE [line: 1]
1 : i32
3 : i32
2 : i32
1 : i32
3 : i32

Bisecting shows that the first bad commit is https://github.com/WebAssembly/binaryen/commit/1a6efdb4233a077bc6e5e8a340baf5672bb5bced . The title of the issue is an assumption due to the description in the first bad commit.