[all-commits] [llvm/llvm-project] a41626: [LLVM][Coroutines] Transform "coro_elide_safe" cal...

[Yuxuan Chen via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a416267a5f3fffb3d1e9d8d53245aef8169c5ddb
      https://github.com/llvm/llvm-project/commit/a416267a5f3fffb3d1e9d8d53245aef8169c5ddb
  Author: Yuxuan Chen <ych at fb.com>
  Date:   2024-09-08 (Sun, 08 Sep 2024)

  Changed paths:
    A llvm/include/llvm/Transforms/Coroutines/CoroAnnotationElide.h
    M llvm/lib/Passes/PassBuilder.cpp
    M llvm/lib/Passes/PassBuilderPipelines.cpp
    M llvm/lib/Passes/PassRegistry.def
    M llvm/lib/Transforms/Coroutines/CMakeLists.txt
    A llvm/lib/Transforms/Coroutines/CoroAnnotationElide.cpp
    M llvm/test/Other/new-pm-defaults.ll
    M llvm/test/Other/new-pm-thinlto-postlink-defaults.ll
    M llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
    M llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
    A llvm/test/Transforms/Coroutines/coro-transform-must-elide.ll

  Log Message:
  -----------
  [LLVM][Coroutines] Transform "coro_elide_safe" calls to switch ABI coroutines to the `noalloc` variant (#99285)

This patch is episode three of the middle end implementation for the
coroutine HALO improvement project published on discourse:
https://discourse.llvm.org/t/language-extension-for-better-more-deterministic-halo-for-c-coroutines/80044

After we attribute the calls to some coroutines as "coro_elide_safe" in
the C++ FE and creating a `noalloc` ramp function, we use a new middle
end pass to move the call to coroutines to the noalloc variant.

This pass should be run after CoroSplit. For each node we process in
CoroSplit, we look for its callers and replace the attributed ones in
presplit coroutines to the noalloc one. The transformed `noalloc` ramp
function will also require a frame pointer to a block of memory it can
use as an activation frame. We allocate this on the caller's frame with
an alloca.

Please note that we cannot safely transform such attributed calls in
post-split coroutines due to memory lifetime reasons. The CoroSplit pass
is responsible for creating the coroutine frame spills for all the
allocas in the coroutine. Therefore it will be unsafe to create new
allocas like this one in post-split coroutines. This happens relatively
rarely because CGSCC performs the passes on the callees before the
caller. However, if multiple coroutines coexist in one SCC, this
situation does happen (and prevents us from having potentially unbound
frame size due to recursion.)

You can find episode 1: Clang FE of this patch series at
https://github.com/llvm/llvm-project/pull/99282
Episode 2: CoroSplit at https://github.com/llvm/llvm-project/pull/99283



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications