[llvm] [Coroutines] Model retcon returns explicitly and upgrade legacy IR (PR #227232)

Weibo He via llvm-commits llvm-commits at lists.llvm.org
Sat Oct 3 06:01:01 PDT 2026


NewSigma wrote:

> I guess my first question would be why this is represented as an alloca parameter, plus a load from that alloca? Esp. taking into account that this requires an aggregate load, this is kind of unfortunate.

Yeah, I agree this is somewhat hacky. The aggregate load is only for formality and gets dropped in `coro-split`.

The returned-continuation ABI returns a value of type `{ptr, ...}`, which is determined by the frontend, and the return values are initialized by `coro.suspend.retcon(...)`. This approach expects `coro.suspend.retcon(...)` to write the alloca and asks the frontend to emit the return value with the correct type.

> Might it make more sense to have something like
> 
> ```llvm
> call void @llvm.coro.end(ptr %hdl, i1 0, token none)
> %coro.ret = call { ptr, i32 } @llvm.coro.ret(ptr %hdl)
> ret { ptr, i32 } %coro.ret
> ```
> 
> instead?

I think it is a tradeoff. We can save the aggregate load but have to design its semantics. Switched-Resume ABI cannot consume the intrinsic, whose return value is explicitly formed. A better signature would be `llvm.coro.ret.retcon()`, and `%hdl` would be dropped because it is destroyed after `coro.end`. It is hard to say where the return value comes from.

> Or seeing how the new alloca load + return seems to always directly follow coro.end in tests, maybe coro.end should be returning the return value?

`coro.end` is heavy and widely used. We dropped its return value and separated it into orthogonal intrinsics in #153404. Adding the return value back would be another breaking change...

https://github.com/llvm/llvm-project/pull/227232


More information about the llvm-commits mailing list