[PATCH] D98638: [RFC][Coroutine] Force stack allocation after await_suspend() call

[Xun Li via Phabricator via cfe-commits]

lxfind added a comment.

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

That's a fair point. I agree that we have no guarantee these are the only two cases.
It does seem to me that coroutine implementation somewhat relies on proper lifetime markers so that data are being put correctly, which may be the fundamental problem we are trying to solve.

> 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