CppCon 2018: Arthur O'Dwyer “Return Value Optimization: Harder Than It Looks”

—
—
Join Arthur O'Dwyer on a deep dive into Return Value Optimization and related topics.

Even C++03 allowed the compiler to "elide" copy construction in certain cases. We'll start with an explanation of the calling convention on a typical machine, showing where the mysterious "return slot" lives, and why it makes sense that C++03 allowed copy elision in certain special cases (but not others). Then we'll show how C++11 (and a subsequent defect report) upped the game by quietly turning the remaining copies into moves, so that the commonly received wisdom these days is that `return std::move(x)` is never necessary and often a pessimization.

...Or is it? We'll show some real-world examples where `return x` quietly copies a large object instead of moving it. We'll explain the little-known notion of a "converting constructor", contrast it with "conversion operator", and show the precise way in which C++17 drops the ball on these examples. Finally, Arthur implemented a Clang compiler warning to detect and suggest fixes for problematic return statements; he'll walk through the relatively painless process of creating that diagnostic, and perhaps inspire you to contribute to Clang yourself!
—
Arthur O'Dwyer

Arthur O'Dwyer started his career writing pre-C++11 compilers for Green Hills Software; he currently writes C++14 for Akamai Technologies. Arthur is the author of "Colossal Cave: The Board Game," "Mastering the C++17 STL" (the book), and "The STL From Scratch" (the training course). He is occasionally active on the C++ Standards Committee and has a blog mostly about C++.
—

*-----*
*-----*

[ashrasmun]

Ultra concise and incredibly useful. Happy to stumble upon that :)

[mockingbird]

Very useful talk learned a lot about x86 asm too. Thanks for those quick overview of the x86 basics on call/return :)

[shahmiBro]

Durian is not a problem, it just a matter of an individual's taste;

[zhivkobogdanov]

It's worth mentioning that copy elision will not be performed, as far as I am aware, if you have multiple return points or some initialization that follows a certain condition. Try to avoid those. :-)

[dennydaydreamer]

For the Cexpr example, if there exists a constructor Cexpr(CexprList&&) that does the slicing by moving, would it have been called?

[dirtbikersteve]

3:00 rdi movs to rax so that once return slot is filled that by convention the return register (rax/eax) holds this pointer to return slot.

[xealit]

16:00 the return IPF64(IPF32&&); - why does it work in this case? The type of the first parameter is not IPF64 here either. - Ah! wait, the constructors are templated, and there is a IPF64(IPF32&&). Did not notice that. And I thought you'd have to make it use the move before:
IPF64 result = get_upstream_callback();
return result;
And it is the same to use IPF32::operator IPF64 probably.

[isitanos]

Not convinced by the example at p.32. It might be impossible to optimize based on a limited view of only the current function, but if the parameter passed is a temporary, it should be possible to keep collapsing until you have only one memory location left.

[notnullnotvoid]

This kind of insanity is why plain old C is still alive and well.

[Xeverous]

In many cases, compilers were better than the standard - but isn't this actually allowed? Can the perform RVO better than the standard says because of the as-if rule?

[JohnDlugosz]

The description is wrong. "he'll walk through the relatively painless process of creating that
diagnostic, and perhaps inspire you to contribute to Clang yourself!" is not included here. This is a shortened version of the presentation.

[User-cvee]

Man this is waaaayy too complicated. I can wrap my head (maybe?) around some of these snippets but on a production code..not really sure.
Great presentation btw. You tried your best but the topic is just too complicated.

[GeorgeTsiros]

uuhm aaah aaahm

I would have walked out in the first minute. Learn to speak.