Output type of local.tee?

[askeksa-google]

With the introduction of static subtyping, the input to a local.tee can be a subtype of the type of the local. This gives two obvious, sound choices for the output type:

1. The type of the local. This is what follows from the typing rules for local.tee (same input, output and local type) combined with implicit upcasting of inputs.
2. The actual type of the input. This is more useful, since it is more precise. On the other hand, it means that local.tee is not equivalent to local.set followed by local.get, and doing the substitution can break validation.

Currently, as far as I can tell, Binaryen implements (1) and V8 implements (2).

What is the intended behavior?

[kripken]

Previous discussion: WebAssembly/reference-types#55

Looks like the status there is that we agreed to keep things as what you call option 1.

[jakobkummerow]

OK, we'll fix that in V8 then.

(Though IMHO it's sad to discard perfectly valid type information, e.g. about non-null-ness in a sequence like (struct.new) (local.tee) (struct.set)...)

[askeksa-google]

Thanks for the pointer.

This ties in with the discussion of non-nullable locals in WebAssembly/function-references#44, in that when locals can't be non-nullable, any value stored through local.tee is forced to discard its nullability, leading to more inserted ref.as_non_null checks in practice.

[kripken]

I'm not opposed to revisiting this topic, btw, I was just pointing out the previous info. Data on code size downsides could be important, I agree.

[taralx]

At the time we were concerned about losing the equivalence. Do we have any data on that equivalence being used?

[kripken]

I explored this in Binaryen, WebAssembly/binaryen#3704 (comment) Overall there is some work to be done in the optimizer there to handle losing that equivalence, but it seems practical.

Now that we have an almost-fully working pipeline I think it's easier to make a decision on this. I'd support using the more specific type of the value, so my previous concerns are no longer valid. Perhaps we can make the change then, maybe in the next GC prototype version?

[kripken]

Noticed in WebAssembly/binaryen#3767 that br_if has a similar situation, where the spec says the type is that of the target block/loop/etc. and not the value flowing through it, which means that like with local.tee we are missing out on more specific type info.

It probably doesn't matter (as mentioned there, I've never seen br_if's value used except in fuzz code), but maybe we should change it for consistency if we change local.tee.

[titzer]

Hmm, I find it odd that br_if loses type information by virtue of a possible control flow transfer to label with a different type. Since it leaves the value on the operand stack when not transferring (i.e. falling through), it makes more sense to me that it shouldn't lose type information.

FWIW I recently made a similar change implementing a source language so that the expression (a = e), i.e. a nested assignment, has the type of e rather than a. I made that change for similar reasons to WebAssembly/reference-types#55.

[tlively]

I agree with @kripken that this would be a good candidate change for the next prototype spec (both for local.tee and for br_if). Are there any other places where we are unnecessarily losing type information?

[titzer]

I also noticed that my implementation in https://github.com/titzer/wizard-engine is actually wrong for br_if and preserves the type. I guess there are no spec tests for this corner case of br_if.

[tlively]

This seems like a simple change we should be able to agree on quickly. @kripken, does preserving the more specific type on local.tee and br_if still sound reasonable to you? Would anyone else object to this change?