Make validation of stale types stricter (#7097)

We previously allowed valid expressions to have stale types as long as
those stale types were supertypes of the most precise possible types for
the expressions. Allowing stale types like this could mask bugs where we
failed to propagate precise type information, though.

Make validation stricter by requiring all expressions except for control
flow structures to have the most precise possible types. Control flow
structures are exempt because many passes that can refine types wrap the
refined expressions in blocks with the old type to avoid the need for
refinalization. This pattern would be broken and we would need to
refinalize more frequently without this exception for control flow
structures.

Now that all non-control flow expressions must have precise types,
remove functionality relating to building select instructions with
non-precise types. Since finalization of selects now always calculates a
LUB rather than using a provided type, remove the type parameter from
BinaryenSelect in the C and JS APIs.

Now that stale types are no longer valid, fix a bug in TypeSSA where it
failed to refinalize module-level code. This bug previously would not
have caused problems on its own, but the stale types could cause
problems for later runs of Unsubtyping. Now the stale types would cause
TypeSSA output to fail validation.

Also fix a bug where Builder::replaceWithIdenticalType was in fact
replacing with refined types.

Fixes #7087.

1 files changed, 31 insertions, 0 deletions

diff --git a/test/lit/passes/issue-7087.wast b/test/lit/passes/issue-7087.wast
new file mode 100644
index 000000000..096c88e5d
--- /dev/null
+++ b/test/lit/passes/issue-7087.wast
@@ -0,0 +1,31 @@
+;; NOTE: Assertions have been generated by update_lit_checks.py --all-items and should not be edited.
+
+;; Regression test for a bug in TypeSSA. TypeSSA creates a new subtype, $t_1,
+;; for use in the struct.new in the global initializer, but ran ReFinalize only
+;; on function code, not on module-level code. As a result, the tuple.make
+;; result type still used $t instead of $t_1 after TypeSSA. This stale type
+;; caused Unsubtyping to incorrectly break the subtype relationship between $t
+;; and $t_1, leading to a validation error. The fix was to refinalize
+;; module-level code in TypeSSA and fix the validator so it would have caught
+;; the stale type.
+
+;; RUN: wasm-opt %s -all --type-ssa --unsubtyping -S -o - | filecheck %s
+
+(module
+ ;; CHECK:      (rec
+ ;; CHECK-NEXT:  (type $t (sub (struct)))
+ (type $t (sub (struct)))
+
+ ;; CHECK:       (type $t_1 (sub $t (struct)))
+
+ ;; CHECK:      (global $g (tuple i32 (ref null $t)) (tuple.make 2
+ ;; CHECK-NEXT:  (i32.const 0)
+ ;; CHECK-NEXT:  (struct.new_default $t_1)
+ ;; CHECK-NEXT: ))
+ (global $g (tuple i32 (ref null $t))
+  (tuple.make 2
+   (i32.const 0)
+   (struct.new $t)
+  )
+ )
+)