[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