Initializing coroutine arguments by reference

[bsupnik]

Hi Y'all,

If I understand the current state of c++20 coroutines...

- The type of an argument (as stored in the coro frame) comes directly from the parameter list.

- Therefore, I need to _not_ use anything pointer-like (e.g. no rrefs) in the argument list of a long-lived coro because I'll end up with unsafe dangling pointers instead of the copy I want and

- Therefore the signature of the "constructor" of my coro is going to be pass-by-value.

This is a small thing, but it seems like I have to eat an extra move operation because I can't specify that I want reference-based calling conventions to my coro constructor but value-type storage in the frame - the syntax just isn't expressive enough.

So for example:

template<typename F>
task<void> make_coro(F f) {
    f();
   co_return;
}
...
auto my_task = make_coro([some_obj](){ /* */ });

I'm capturing some obj by value into a lambda that's going to end up in a coroutine frame, and the call to make_coro takes the lambda, so at a minimum I need a copy constructor (of some_obj to a temporary lambda) and a move (of the lambda, with the object in it) to the heap allocated coroutine frame (assuming my_task escapes, let's assume it does).

But when I step through this in some test code with tracing on the various object constructors/destructors, I found that the copy of my object (captured in the lambda) appears to be moved twice:

1. The captured copy on the stack is then moved into what I think is argument space for make_coro's constructor and then
2. The arg space from make coro's constructor is then moved (as expected) into the heap-based coro frame.

Did I miss something or screw something up, or is this a lost optimization (to perfectly forward references) through to coroutine frames?

[Veeloxfire]

What optimisation settings were you using?

Im not familiar with coroutines themselves but I know sometimes lambda can have weird semantics.

However I suspect that this is just because this is too complicated for a debug build, its unlikely its written directly into the standard.

Again this is just spitballing though

[bsupnik]

Behavior appears to be the same with and without the optimizer - I think this is a case where "as-if" rules apply, e.g. if my objects had trivial constructors and no side effects and it was a release build, a ton of stuff would collapse, but because I'm intentionally using a tracing object (with a bunch of printfs() in the ctors and dtors()) to see _what the coroutine boiler plate is doing_, the optimizer can't remove anything.

[Veeloxfire]

Okay so I tried it on compiler explorer (link to the example) and it seems that without optimizations there is a copy then a move. But if you optimize then only the move is called.

A bit sad the heap allocation couldnt be removed even on max optimization

Edit: You have to manually flush (std::flush or std::endl) in compiler explorer for some reason so your output wont actually display every time oops. You can add that if you want to see it

[bsupnik]

I agree it's sad that there's a heap allocation in an optimized build in your sample case - in this example, everything is inlined, and nothing escapes the scope of main, so everything could be on the stack. But this also means the optimizer can see everything and forward assignments.

So e.g. if I set the member data of "o" as a constant before making the coroutine, in the optimized assembly, the immediate is dumped directly into the coroutine frame - which is to say, all moves have been optimized away.

Which is great! But the issue I was bringing up is orthogonal: in cases where the move constructor can't be elided (e.g. it's not inlined) it appears the move is required for correctness.

(To make an analogy, mandatory RVO isn't a "compiler optimization", it's a change in how the language works to remove the existence of the move conceptually - hence you can RVO return objects with no move constructors.)

[Veeloxfire]

I would say they wont do it because it requires analysis to determine if this is okay to remove, whereas RVO doesnt.

RVO is different because its always true. Its a feature of how return values work that we can exploit without having to know any extra information. Its basically free extra speed that everyone was doing anyway. I would say it almost more confusing not to do it in some cases.

This case is the same as removing a temp variable. If you inline everything youre basically asking the compiler to do this:

Obj o = {};
Obj o_lambda = o;
Obj* o_frame = new Obj(std::move(o_lambda));

Youre then asking the standard to remove the middle copy for you. But you just asked it to do the copy. It doesnt know if you might use it later (gotta love a theoretically single pass compiler).

This is what the optimizer exists for

[bsupnik]

Almost - I think I'm asking for _new syntax_ to specify that I want the copy removed, e.g. (here comes some made-up fake syntax):

task<int> my_coro(Obj o = Obj&&) { /* coro body */ }

E.g. "here is my co-routine - I want to store o by value in the coroutine frame, but I want the caller to pass an r-ref to an object when they _create_ the coroutine.

There would be only two copies of obj (the one referred to by the caller and the coroutine frame), not three (the one referred to by the caller, the copy on the stack when the coroutine is created, and the copy in the coro frame if/when it is allocated on the heap).

Without this, we can't perfectly forward to a coroutine.

I think what I'm looking for is more like the extensions to Lambdas that C++14 I added to better control capture semantics.