Bug 278496 – [WASM] Expression stack element types should widen to match target types after conditional branch

• Status: RESOLVED
• Resolution: FIXED
• Component: WebAssembly

[David Degazio]

When we execute a conditional branch instruction in WASM, like br_if (or br_on_null/br_on_cast_fail with the GC proposal), the spec tells us the following:

  br_if l
   - The label C.labels[l] must be defined in the context.
   - Let [t*] be the result type C.labels[l].
   - Then the instruction is valid with type [t* i32] -> [t*].

So, even if we don't take the branch, the types of the values on the stack are taken from the label's result types. The spec does *not* merely say that the types on the stack must match the label's result types, the results *are* the results specified by the branch target. This was discussed and confirmed in https://github.com/WebAssembly/gc/issues/516.

As an example of why this is observable, consider the following:

  (func $f (param (ref func)))
  (func $g
    block (result funcref)
      ref.func $f
      i32.const 0
      br_if 0
      call $f
    end
  )

ref.func $f produces a non-nullable reference to a func, but the result type of the block is funcref aka (ref null func). We unify (ref func) onto (ref null func) successfully in br_if via subtyping. This *also* means we should *re-type* the value on the stack from (ref func) to (ref null func). As a result, we can no longer call $f at the end of the block, because $f expects a non-nullable reference but our stack type is now nullable. Weird!

We currently don't implement this behavior, but we should, in order to conform to the spec and pass more recent versions of the spec tests.

[Radar WebKit Bug Importer]

<rdar://problem/134449160>

[David Degazio]

Pull request: https://github.com/WebKit/WebKit/pull/32553

[EWS]

Committed 282624@main (e947e7ebf9d2): <https://commits.webkit.org/282624@main>

Reviewed commits have been landed. Closing PR #32553 and removing active labels.