[all-commits] [llvm/llvm-project] 00c527: [Coro] Allow spilling @llvm.coro.suspend() to the ...

[Hans Wennborg via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 00c527abab3dfea5f3122f8151d69e77655eb033
      https://github.com/llvm/llvm-project/commit/00c527abab3dfea5f3122f8151d69e77655eb033
  Author: Hans Wennborg <hans at hanshq.net>
  Date:   2025-03-27 (Thu, 27 Mar 2025)

  Changed paths:
    M llvm/lib/Transforms/Coroutines/SpillUtils.cpp
    A llvm/test/Transforms/Coroutines/coro-spill-suspend.ll

  Log Message:
  -----------
  [Coro] Allow spilling @llvm.coro.suspend() to the coro frame (#133088)

It was excluded from spilling in a263a60, possibly by accident.

In the linked bug, we hit a situation like this:

```
  %s = call @llvm.coro.suspend(...)
             |
       switch (%s)
case v1: /       \ case v2:
        ...      ...
         |       suspend point
         |       ...
         \       /
 %x = phi [v1] [v2]
             |
            ...
             |
         use(%x)
```

Instcombine will notice that %x correlates exactly with %s, and so
use(%x) becomes use(%s).

However, corosplit would substitute different values for %s when
splitting the function, so even though %s had a particular value when
control actually passed through the switch, it could have a *different*
value when reaching use(%s).

This illustrates that while IR from the frontend typically does not use
these suspend return values across suspend points, mid-level
optimizations on the presplit coroutine may introduce new uses of
suspend values, so they must be considered eligible to spill to the
coroutine frame.

Fixes: #130326



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