[llvm] [CoroElide] Remove restriction that the ramp function be inlined (PR #211163)

[Weibo He via llvm-commits]

NewSigma wrote:

> > > Is there any realistic use case?
> > 
> > 
> > The pattern is uncommon but possible. See [godbolt](https://godbolt.org/z/MG8fvddcP). It's not production-proven, but demonstrates the mechanics clearly.
> 
> Got your point. The point is to filtering the uncommon case to save some computation times. As in most cases, the coroutine itself is not elidable.
> 
> BTW, I found coro-eliding is not always an optimization. You can take a look at: https://chuanqixu9.github.io/c++/2026/03/27/C++20-Coroutines-from-compiler-and-library-authors-perspective.en.html

Yeah. I read it a while ago and found it interesting and insightful.

Specific to the problem in the post: the callee is inlined into the caller. We apply coro elision, replacing `malloc` with an `alloca`. This `alloca` is then collected into the caller’s frame, which can introduce additional space overhead.

I believe part of the problem is that we currently do not emit lifetime markers for elided coroutines. As a result, `CoroSplit` must conservatively place the `alloca` into the frame when its address escapes.

In the current patch, the callee is elided *before* being inlined into the caller. The inliner then adds proper lifetime markers for the `alloca`. This should avoid the overhead after inlining. I also have a local patch that lowers `coro.begin` to `lifetime.start` and `coro.dead` to `lifetime.end`. It appears to work, though I haven't tested it extensively yet.

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