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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
