More precise livenes analysis for locals under Asyncify

[sbc100]

I've been trying to add an externref to emscripten here:
emscripten-core/emscripten#26964

And its failing with: Fatal: Asyncify does not yet support non-number types, like references (see #3739).

Rather than push to land the fix to #3739, I think my particulur use case might be fixed by resolving this TODO in Asyncify:

binaryen/src/passes/Asyncify.cpp

Lines 1597 to 1599 in 3029fbb

	// The relevant live locals are ones that are alive at an unwind/rewind
	// location. TODO look more precisely inside basic blocks, as one might stop
	// being live in the middle

The externref I'm using is not live after the call to the suspending function, so it should not need to be saved or restored.

How hard would it be to fix that TODO? Presumably it would make Asyncify in general more efficient?

[sbc100]

Actually it sounds like this would not be enough to fix the issue because the externref is always live the suspension point in my case (emscripten_promise_ref_await_unchecked(promise)).

[sbc100]

CC @tlively @kripken

[kripken]

Fixing that TODO would help the case where a local stops being live in the middle of a basic block. E.g.

x = y + 10;  // x is live
*z = x;      // x stops being live
foo();       // x is not live here, no need to save it
x = y + 20;  // x is live again
*z = x;

If the x = y + 20 were deleted, x would be live during foo().

This would make Asyncify more powerful, but probably not by a lot, I'd guess. You'd have to get really lucky to benefit.

[sbc100]

How about this case:

x = y + 10;  // x is live
*z = x;      // x stops being live
foo(x);       // x is passed to foo, but not live after it, so when re-winding we can just pass null/zero and no need to save x

I think we can avoid saving x in this case too, but the rewind logic might get a lot more complex :(

[kripken]

Ah, yes, I suppose we'd need to consider x as alive if it is sent to the function call.