[PATCH] D90612: Start of an llvm.coro.async implementation

[John McCall via Phabricator via llvm-commits]

rjmccall added a comment.

In D90612#2384323 <https://reviews.llvm.org/D90612#2384323>, @lxfind wrote:

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


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90612/new/

https://reviews.llvm.org/D90612