ChuanqiXu9 wrote: > @ChuanqiXu9, > > (1) I'm not actually changing `libc++`. I just added an end-to-end test for > this compiler feature. It's backwards- and forwards-compatible, so I don't > think there's any risk to bundling it with this PR.
This is not about risks. It is simply about developing processes. In another word, it will be faster to merge this if you split it. > > (2) My patch isn't a fully general solution to #148380. Rather, it's a > (probably) better solution to the more narrow class of problems of > short-circuiting suspends. > > To use my thing, two things have to be true: > > * You actually have to opt into the new attribute and define > `await_suspend_destroy` to get the perf benefits. > * You can only do so if your `await_suspend` would destroy the coro > **unconditionally**. > > When both of those are true (opt-in & unconditional deestroy), it results in > a much simpler compilation setup -- HALO, less IR, less optimized code, > better perf. In another word, if users want, this patch can cover https://github.com/llvm/llvm-project/issues/148380, right? Could you have a test for this? 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
