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

CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2018
-
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++.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

[@ashrasmun1]

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

[@mockingbird3809]

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

[@CppCon]

Glad it was helpful!

[@dingliu5273]

Brilliant talk, I love it!

[@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.

[@MatthijsvanDuin]

That part is completely obvious, at the very least to the speaker (given his experience working on compilers). The big question is why this convention exists. It has no obvious utility and no such convention exists e.g. on ARM or PowerPC.

[@shahmiBro1]

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

[@zhivkobogdanov2845]

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. :-)

[@axelBr1]

I believe the following will work (i.e. not create a copy), but uses a Move. If a is made const it might work, (i.e. not make a copy)
A foo() {
if ( condition ) {
A a = …;
…
return a;
} else {
A a = …;
…
return a;
}
};

[@yuehuajia3176]

good talk.

[@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.

[@dennydaydreamer]

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

[@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?

[@MatthijsvanDuin]

All the headache here is related to classes with user-defined copy and/or move constructors, in which case copy elision (including RVO) and implicit move are semantic changes that do not fall under the as-if rule and therefore require explicit permission from the standard.

[@notnullnotvoid]

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

[@VioletGiraffe]

And also why it sucks.

[@bobweiram6321]

Ada is the way.

[@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-cv4ee]

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.

[@vivekveer3272]

who hurt you dude? a bit of stuttering is fine, much better than a robotic presentation. The content was good too.

[@yuehuajia3176]

good talk.