[Wasm GC] Local-Subtyping pass (#3765)

If a local is say anyref, but all values assigned to it are something
more specific like funcref, then we can make the type of the local
more specific. In principle that might allow further optimizations, as
the local.gets of that local will have a more specific type that their
users can see, like this:

(import .. (func $get-funcref (result funcref)))

(func $foo (result i32)
  (local $x anyref)
  (local.set $x (call $get-funcref))
  (ref.is_func (local.get $x))
)
=>
(func $foo (result i32)
  (local $x funcref) ;; updated to a subtype of the original
  (local.set $x (call $get-funcref))
  (ref.is_func (local.get $x)) ;; this can now be optimized to "1"
)

A possible downside is that using more specific types may not end
up allowing optimizations but may end up increasing the size of
the binary (say, replacing lots of anyref with various specific
types that compress more poorly; also, for recursive types the LUB
may be a unique type appearing nowhere else in the wasm). We
should investigate the code size factors more later.

1 files changed, 3 insertions, 0 deletions

diff --git a/test/lit/help/optimization-opts.test b/test/lit/help/optimization-opts.test
index 3350015a1..0d4ed48a8 100644
--- a/test/lit/help/optimization-opts.test
+++ b/test/lit/help/optimization-opts.test
@@ -292,6 +292,9 @@
 ;; CHECK-NEXT:   --local-cse                                   common subexpression elimination
 ;; CHECK-NEXT:                                                 inside basic blocks
 ;; CHECK-NEXT:
+;; CHECK-NEXT:   --local-subtyping                             apply more specific subtypes to
+;; CHECK-NEXT:                                                 locals where possible 
+;; CHECK-NEXT:
 ;; CHECK-NEXT:   --log-execution                               instrument the build with
 ;; CHECK-NEXT:                                                 logging of where execution goes
 ;; CHECK-NEXT: