Skip to content

More precise livenes analysis for locals under Asyncify #9038

Open

Description

@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:

// 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?

Activity

  1. sbc100 commented on Aug 24, 2026

    @sbc100
    MemberAuthor

    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)).

  2. sbc100 commented on Aug 24, 2026

    @sbc100
    MemberAuthor
  3. kripken commented on Aug 25, 2026

    @kripken
    Member

    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.

  4. sbc100 commented on Aug 25, 2026

    @sbc100
    MemberAuthor

    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 :(

  5. kripken commented on Aug 25, 2026

    @kripken
    Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions