This is an archive of the discontinued LLVM Phabricator instance.

Start of an llvm.coro.async implementation
ClosedPublic

Authored by aschwaighofer on Nov 2 2020, 7:44 AM.

Details

Summary

This patch adds the async lowering of coroutines.

This will be used by the Swift frontend to lower async functions. In
contrast to the retcon lowering the frontend needs to be in control
over control-flow at suspend points as execution might be suspended at
this points.

This is very much work in progress and the implementation will change as
it evolves with the frontend. As such the documentation is lacking
detail as some of it might change.

rdar://70097093

Diff Detail

Event Timeline

aschwaighofer created this revision.Nov 2 2020, 7:44 AM
aschwaighofer requested review of this revision.Nov 2 2020, 7:44 AM
tschuett added inline comments.
llvm/docs/Coroutines.rst
1164

async?

1188

async?

aschwaighofer added inline comments.Nov 2 2020, 8:42 AM
llvm/docs/Coroutines.rst
1164

yes. Thank you.

1188

Yes. Thank you.

Address comments and lint formatting errors

Fix more lint errors

Looks good to me as a first pass.

llvm/lib/Transforms/Coroutines/CoroFrame.cpp
1883

If it makes things easier, you could make the dependency on the context argument implicit, since I think you rely on it being in a particular position anyway.

This revision was not accepted when it landed; it landed in state Needs Review.Nov 4 2020, 7:34 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
lxfind added a comment.Nov 9 2020, 5:35 PM

Curious, is the plan to eventually replace .recon lowering with .async lowering? If so, would you mind explain in a bit more detail what's the advantage of .async over .retcon lowering and what motivates this new lowering? Thanks!

Curious, is the plan to eventually replace .recon lowering with .async lowering?

No; they will exist side-by-side and be used for different purposes.

If so, would you mind explain in a bit more detail what's the advantage of .async over .retcon lowering and what motivates this new lowering? Thanks!

The swiftasync lowering is geared towards the needs of async functions (whose activations follow a traditional call-stack discipline, but which need to be allocated outside of the C stack), while the retcon lowering is geared towards accessors (whose activation are true (if limited) coroutines, but which tend to be short-lived and statically scoped). The most significant differences are centered around taking advantage of the presence of a fast async-thread-local stack allocator, as well as transfers of responsibility and control between the async caller and callee.

The way that the coroutine passes out a frame size that the caller is responsible for allocating is an idea that we really should've explored in the retcon.once lowering — it would mean more work for callers (who would need to dynamically alloca the right amount of memory), but accessors would never need to allocate their frame dynamically with malloc, which is probably a better trade-off overall.