Skip to content

Conversation

rjmccall
Copy link
Contributor

I'm not actually sold that the runtime has to do a stack allocation here, because it only really does it because it creates a result buffer in the future that it should be able to avoid. But it's indisputable that it currently does so, and we may come up with good reasons for it to continue to do so even if we remove the current allocation, so modeling the allocation is the right thing to do.

Fixes rdar://109850951

@rjmccall
Copy link
Contributor Author

@swift-ci Please test

functions.

These were introduced in an early draft implementation of async let, but
never used by a released compiler. They are not used as symbols by any
app binaries. There's no reason to keep carrying them.

While I'm at it, dramatically improve the documentation of the remaining
async let API functions.
@rjmccall rjmccall force-pushed the async-let-runtime-realism branch from 6a92685 to 854242e Compare September 26, 2025 21:54
@rjmccall
Copy link
Contributor Author

@swift-ci Please test

Reflect the potential stack allocation of the begin/finish pair in SIL,
which should prevent the optimizer from trying to move stack allocations
around them.

I'm not actually sold that the runtime *has* to do a stack allocation here,
because it only really does it because it creates a result buffer in the
future that it should be able to avoid. But it's undisputable that it
currently does so, and we may come up with good reasons for it to continue
to do so even if we remove the current allocation, so modeling the allocation
is the right thing to do.

Fixes rdar://109850951
@rjmccall rjmccall force-pushed the async-let-runtime-realism branch from 854242e to 8cd55ec Compare September 27, 2025 00:04
@rjmccall
Copy link
Contributor Author

@swift-ci Please test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant