SubtypingDiscoverer: Differentiate non-flow subtyping constraints (#6344)

When we do a local.set of a value into a local then we have both a subtyping constraint - for
the value to be valid to put in that local - and also a flow of a value, which can then reach
more places. Such flow then interacts with casts in Unsubtyping, since it needs to know
what can flow where in order to know how casts force us to keep subtyping relations.

That regressed in the not-actually-NFC #6323 in which I added the innocuous lines
to add subtyping constraints in ref.eq. It seems fine to require that the arms of a
RefEq must be of type eqref, but Unsubtyping then assuming those arms flowed into
a location of type eqref... which means casts might force us to not optimize some
things.

To fix this, differentiate the rare case of non-flowing subtyping constraints, which is
basically only RefEq. There are perhaps a few more cases (like i31 operations) but they
do not matter in practice for Unsubtyping anyhow; I suggest we land this first to undo
the regression and then at our leisure investigate the other instructions.

1 files changed, 4 insertions, 0 deletions

diff --git a/src/passes/StringLowering.cpp b/src/passes/StringLowering.cpp
index 1e16295cd..e0d3fbad0 100644
--- a/src/passes/StringLowering.cpp
+++ b/src/passes/StringLowering.cpp
@@ -478,6 +478,10 @@ struct StringLowering : public StringGathering {
         // Only the type matters of the place we assign to.
         noteSubtype(a, b->type);
       }
+      void noteNonFlowSubtype(Expression* a, Type b) {
+        // Flow or non-flow is the same for us.
+        noteSubtype(a, b);
+      }
       void noteCast(HeapType, HeapType) {
         // Casts do not concern us.
       }