[PATCH] D94834: [Coroutine] Do not CoroElide if there are musttail calls

[Chuanqi Xu via Phabricator via llvm-commits]

ChuanqiXu added a comment.

In D94834#2521983 <https://reviews.llvm.org/D94834#2521983>, @lxfind wrote:

> In D94834#2521744 <https://reviews.llvm.org/D94834#2521744>, @ChuanqiXu wrote:
>
>> In D94834#2521729 <https://reviews.llvm.org/D94834#2521729>, @lxfind wrote:
>>
>>>> And I think there are two cases about this example:
>>>> (1) The musttail call is dominated by  `@llvm.subfn.addr(%handle, 1)` calls. Then `%handle` is destroyed at the musttail call, so it makes no sense that the musttail call returns `%handle`.
>>>> (2) The musttail call isn't dominated by  `@llvm.subfn.addr(%handle, 1)` calls. Then the musttail call may returns `%handle`. And it doesn't matter since `%handle` won't be elided in this case.
>>>
>>> In case (1), why is it that '%handle' must be destroyed at the musttail call?
>>
>> In my mind, `@llvm.subfn.addr(%handle, 1)` means a call which would destroy `%handle`. And CoroElide Pass also treat the call as a lifetime end marker for `%handle`. CoroElide pass only elides coroutine handle who is guarded by `@llvm.subfn.addr(%handle, 1)` .
>
> I guess that means we could improve this by teaching alias analysis that llvm.subfn.addr kills the handle.

I agree with that is a good solution to use AA if we can teach AA that `llvm.subfn.addr(%handle, 1)` kills `%handle`. But for my understanding to AA, it is not easy to do so. Maybe we need to refactor both AA and CoroElide to do that. 
Let's go back to this bug. I think we can solve this problem by removing the static check for musttail call in `removeTailCallAttribute`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94834