ChuanqiXu added a comment. In D98638#2630778 <https://reviews.llvm.org/D98638#2630778>, @lxfind wrote:
> What do you think is the fundamental problem, though? It is hard to give a formal description for the problem. Let me try to explain it. What I want to say here is about rules that decide whether a value should be put on the coroutine frame. Initially, we put values on the frame for whose uses are crossing suspend points with their definition. Then, we put values on the frame for whose uses are crossing suspend points with their definition and uses are not escaped. In this patch, we want to put values on the frame for whose uses are crossing suspend points with their definition and uses are not escaped but except the result of symmetric transfer and %gro. Then we need to answer the question: how can we **prove** that the result of symmetric transfer and %gro are the **only** exceptions from the above rules. Or how can we know the list of exceptions wouldn't get longer and longer in the future? Then go back to the example in the summary. From my point of view, the key problem is that our escape analysis isn't powerful enough. I don't ask us to do excellent escape analysis. It may beyond our abilities. I just want to say how can we know the result of symmetric transfer and %gro are the only exceptions. In D98638#2630778 <https://reviews.llvm.org/D98638#2630778>, @lxfind wrote: > Whether or not the current coroutine frame would be destroyed completely > depend on the implementation of await_suspend. So we cannot predict or know > in advance. Therefore, the temporary handle returned by await_suspend must be > put on the stack. I don't really see any other solutions other than this. OK. Although the main stream implementation of await_suspend only destroy the coroutine handle in the final awaiter, the compiler can't assume the normal await_suspend won't destroy it. So I agree to guard the result of the await_suspend to make it put on the stack. At least, it would reduce the size of the coroutine frame. Then if we want to put the result of the await_suspend in the stack, I think we can do it under CodeGen part only. It should be easy to judge the return type of await_suspend and create a call to llvm.coro.forcestack to the return value of await_suspend. In D98638#2630778 <https://reviews.llvm.org/D98638#2630778>, @lxfind wrote: > Well, I guess another potential solution is to force emitting lifetime > intrinsics for this part of coroutine in the front-end. I am not sure if this is a good idea. May it break the guide principle in LLVM? This need to be reviewed by others. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98638/new/ https://reviews.llvm.org/D98638 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
