[all-commits] [llvm/llvm-project] 17631a: [Coroutines] Store the index for final suspend poi...

[Chuanqi Xu via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 17631ac676bc44b7fd5c79abc66844efb4e1b533
      https://github.com/llvm/llvm-project/commit/17631ac676bc44b7fd5c79abc66844efb4e1b533
  Author: Chuanqi Xu <yedeng.yd at linux.alibaba.com>
  Date:   2022-08-26 (Fri, 26 Aug 2022)

  Changed paths:
    A clang/test/CodeGenCoroutines/coro-destructor-of-final_suspend.cpp
    M clang/test/CodeGenCoroutines/pr56919.cpp
    M llvm/lib/Transforms/Coroutines/CoroInternal.h
    M llvm/lib/Transforms/Coroutines/CoroSplit.cpp
    M llvm/lib/Transforms/Coroutines/Coroutines.cpp
    A llvm/test/Transforms/Coroutines/coro-split-final-suspend.ll

  Log Message:
  -----------
  [Coroutines] Store the index for final suspend point if there is unwind coro end

Closing https://github.com/llvm/llvm-project/issues/57339

The root cause for this issue is an pre-mature optimization to eliminate
the index for the final suspend point since we feel like we can judge
if a coroutine is suspended at the final suspend by if resume_fn_addr is
null. However this is not true if the coroutine exists via an exception
in promise.unhandled_exception(). According to
[dcl.fct.def.coroutine]p14:

> If the evaluation of the expression promise.unhandled_exception()
> exits via an exception, the coroutine is considered suspended at the
> final suspend point.

But from the perspective of the implementation, we can't set the coro
index to the final suspend point directly since it breaks the states.

To fix the issue, we block the optimization if we find there is any
unwind coro end, which indicates that it is possible that the coroutine
exists via an exception from promise.unhandled_exception().

Test Plan: folly