[PATCH] D66230: [coroutine] Fixes "cannot move instruction since its users are not dominated by CoroBegin" problem.

Xun Li via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 3 09:31:49 PDT 2020


lxfind added a comment.

In D66230#2246830 <https://reviews.llvm.org/D66230#2246830>, @rjmccall wrote:

> Yes, we at Apple had similar problems and basically had to revert this internally.  The basic problem is that LLVM's `alloca` representation is not well-suited for coroutines — we really need a guarantee that there are no stack allocations live across the `coro.begin`, or at least none that stay alive until the first suspend.  That would be easy with something like SIL's `alloc_stack`, but LLVM's desire to push local allocations into the entry block really makes it difficult to even talk about the appropriate restrictions here.
>
> Maybe we could force all local allocations in coroutines to be done with the `llvm.coro.alloca.*` intrinsics that I added?  We could then actually verify that no allocations are live across the `coro.begin`.  That would require a fair bit of abstraction in Clang, though, and possibly in some other passes that introduce allocas, and it might severely block optimization unless we teach mem2reg how to handle those intrinsics.

Thank you @rjmccall for your feedback! Yes I agree with you that there seems no practical way to make this work 100% of the time. I made an attempt in D86859 <https://reviews.llvm.org/D86859> which should at least make this more robust and handle majority of the cases. In the meanwhile I will look into how this is done using coro.alloca. It would be great if you could help take a look at D86859 <https://reviews.llvm.org/D86859> too.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66230/new/

https://reviews.llvm.org/D66230



More information about the llvm-commits mailing list