[all-commits] [llvm/llvm-project] 703733: [Coroutines] [CoroElide] Don't think exceptional t...

[Chuanqi Xu via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f
      https://github.com/llvm/llvm-project/commit/7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f
  Author: Chuanqi Xu <yedeng.yd at linux.alibaba.com>
  Date:   2023-08-23 (Wed, 23 Aug 2023)

  Changed paths:
    M clang/test/CodeGenCoroutines/coro-halo.cpp
    A clang/test/CodeGenCoroutines/pr59723.cpp
    M llvm/lib/Transforms/Coroutines/CoroElide.cpp

  Log Message:
  -----------
  [Coroutines] [CoroElide] Don't think exceptional terminator don't leak coro handle unconditionally any more

Close https://github.com/llvm/llvm-project/issues/59723.

The fundamental cause of the above issue is that we assumed the memory
of coroutine frame can be released by stack unwinding automatically
if the allocation of the coroutine frame is elided. But we missed one
point: the stack unwinding has different semantics with the explicit
coroutine_handle<>::destroy(). Since the latter is explicit so it shows
the intention of the user. So we can blame the user to destroy the
coroutine frame incorrectly in case of use-after-free happens. But we
can't do so with stack unwinding.

So after this patch, we won't think the exceptional terminator don't
leak the coroutine handle unconditionally. Instead, we think the
exceptional terminator will leak the coroutine handle too if the
coroutine is leaked somewhere along the search path.

Concretely for C++, we can think the exceptional terminator is not
special any more. Maybe this may cause some performance regressions.
But I've tested the motivating example (std::generator). And on the
other side, the coroutine elision is a middle end opitmization and not
a language feature. So we don't think we should blame such regressions
especially we are correcting the miscompilations.