LUBFinder: Update nulls

[kripken]

It is common in GC code to have stuff like this:

x = null;
..
x = Data();

Nulls in wasm have a type, and if that initial null has say anyref then
before this PR we would keep the type of x as anyref. However,
while nulls have types, all null values are identical, and so we can
in fact change x's type to a nullable reference of Data, by also
changing the null's type. That is, the LUB of

(ref.null any)  ,  (struct.new $Data)

can be (ref null $Data) if we update that null to

(ref.null $Data)

This PR adds that optimization to LUBFinder, and does the relevant
minor work to get that supported in the two passes using that
helper. The LUBFinder now tracks nulls and updates them at the
end if it makes sense to do so.

An annoyance is that test/lit/passes/dae-gc-refine-return.wast used
a lot of nulls in that test file. But now the pass can optimize those. This
PR therefore adds blocks to wrap around them, which avoids changing
anything in the test there, though it is not a small diff sadly.

[tlively]

Should be (ref.null $Data) in the PR description where it describes the result of the transformation.

[kripken]

@tlively Do you mean to add a . there? But the sentence is:

That is, the LUB of [..two instructions..] can be (ref null $Data).

The LUB is a type (and not a ref.null instruction) so I think that is correct as it is?

[tlively]

Yeah sorry I mistyped that comment originally. See the edit.

can be (ref null $Data) if we update that null to

(ref.null any)

should be

can be (ref null $Data) if we update that null to

(ref.null $Data)

[kripken]

Oh, right, thanks! Fixed.

[tlively]

Nice!

[tlively]

Would it make sense to reuse note(Type) here rather than introducing a new vector?

[kripken]

I guess that could be more efficient. It would leave noticeable traces, though, if you look at the internals, even though they should be hidden from the outside.

[tlively]

Yeah, fair enough. No reason to mess with longer-lived state here.

[tlively]

This looks dangerous because get() could update nulls even if it returns the original type, in which case we would have to return true to refinalize. However, I think that if we get here, it must be that the lub is not originalType because we would have returned already after one of the calls to processReturnValue or processReturnType. So can we turn this into an assertion that the lub is not equal to originalType?

[kripken]

Hmm, good point, this does look dangerous. I'll try to figure out something.

We can't assert here, because while you are right that the LUB is not originalType, it might still become originalType during the final computation - when we take into account nulls. But, that case is not dangerous to us here. It's annoying that the invariants that makes this safe are in the other file, which makes it hard to reason about safety here, which I'll think on.

[tlively]

What if the nulls are not all the same type?