[PATCH] New warning -Wpessimizing-move to catch when removing calls to std::move in return statements will result in NRVO

Richard Smith richard at metafoo.co.uk
Wed Feb 18 19:49:43 PST 2015


On Wed, Feb 18, 2015 at 6:36 PM, Richard Trieu <rtrieu at google.com> wrote:

> So then something like this:
>
>   struct S{};
>   S test(bool cond) {
>     S s1, s2;
>     if (cond)
>       return std::move(s1);
>     return std::move(s2);
>   }
>
> would be better with the std::move's removed:
>
>   struct S{};
>   S test(bool cond) {
>     S s1, s2;
>     if (cond)
>       return s1;
>     return s2;
>   }
>
> even though NRVO would not be triggered since different local variables
> are used?


Yes, even though *our implementation of* NRVO would not be triggered :-) A
sufficiently smart compiler could notice that S's default constructor is
trivial and rewrite the above to:

  S test(bool cond) {
    if (cond) {
      S s1;
      return s1;
    }
    S s2;
    return s2;
  }

That same sufficiently smart compiler could then perform NRVO for both
variables and return statements (in fact, Clang can and should perform NRVO
for the above case, but our NRVO is really dumb today.) The produced
warnings shouldn't depend on how smart our NRVO happens to be.

Putting this into the initialization code (in SemaInit) also lets us catch
other cases with largely the same codepaths, such as:

X f();
X x = std::move(f()); // another form of pessimizing move, disables
copy-elision

http://reviews.llvm.org/D7633
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150218/20a66dfd/attachment.html>


More information about the cfe-commits mailing list