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

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

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

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

[@dennydaydreamer]

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

[@shahmiBro1]

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

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

[@dingliu5273]

Brilliant talk, I love it!

[@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; } };

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

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

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

[@yuehuajia3176]

good talk.

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