[libcxx-commits] [clang] [libcxx] Elide suspension points via [[clang::coro_await_suspend_destroy]] (PR #152623)
Chuanqi Xu via libcxx-commits
libcxx-commits at lists.llvm.org
Mon Aug 11 22:46:21 PDT 2025
ChuanqiXu9 wrote:
> Thanks! One more question @ChuanqiXu9 -- I now have a [pile of smallish fixes](https://github.com/llvm/llvm-project/pull/152623#issuecomment-3177095986) to make. Are you still thinking about the overall design of this PR, or should I go ahead and polish it up for merging?
I feel good with the ideas. Let's address these comments and try to merge it.
>
> > test for #148380 to show we can cover that in certain cases
>
> Ok, this sounds simple enough. I added that to my to-do list for the next revision.
>
> > The core idea is to avoid generating await.suspend intrinsics conditionally. I am open to the conditions.
>
> Ah, now I understand. Your idea ties back to the complex (for me, I didn't spend the necessary time reading the relevant PRs and Phabricator thread!) reasons that the `await.suspend.XXX` intrinsics were introduced in the first place.
>
> It sounds cool in principle, but:
>
> * That's a separate work-stream, right?
Yes. That is a casual chat. Not a requirement for you or this PR.
> * Without deeply understanding the old mis-optimization bug, I doubt I'd be good at coming up with this conditions or use-cases for this class of attributes.
>
> If you're thinking about this actively, and you think that my knowledge of e.g. `folly/coro` is useful for your decision-making, then I can make some time to think about it, or VC about it, and/or you could start a Discourse thread about it?
If you want to understand this fully, you can read it at: https://github.com/llvm/llvm-project/issues/56301 The root cause is complex as it relates to the design of LLVM Coroutine IRs and LLVM middle end optimizations. But the higher level key point is, the LLVM awaiter suspend intrinsics may affect the performance. The problem we're handling is the resumer/destroyer in the await_suspend, especially the coroutine is resumed/destroyed in **another thread** while the await_suspend is executing.
As far as I know, this is reported from google's internal repo, so I `folly/coro` may not be affected by this. But `folly/coro` will be a good candidate in the open source world to show the usefulness of coroutines optimization. Also I think our library (https://github.com/alibaba/async_simple) is a good candidate too as it is much simpler and cheaper.
https://github.com/llvm/llvm-project/pull/152623
More information about the libcxx-commits
mailing list