[PATCH] New warning -Wpessimizing-move to catch when removing calls to std::move prevent optimization

[Richard Smith]

================
Comment at: lib/Sema/SemaInit.cpp:3245-3246
@@ +3244,4 @@
+    return;
+  if (SemaRef.Diags.isIgnored(diag::warn_pessimizing_move_on_initialization,
+                              InitExpr->getLocStart()))
+    return;
----------------
This check is not especially cheap, and the code below will be cheap in most cases; it's probably better to omit this.

================
Comment at: lib/Sema/SemaInit.cpp:3249
@@ +3248,3 @@
+
+  const CallExpr *CE = dyn_cast<CallExpr>(InitExpr);
+  if (!CE || CE->getNumArgs() != 1)
----------------
Maybe `IgnoreParens` before the cast?

================
Comment at: lib/Sema/SemaInit.cpp:3259
@@ +3258,3 @@
+
+  const Expr *Arg = CE->getArg(0)->IgnoreImplicit();
+  if (!Arg->isRValue() || !Arg->getType()->isRecordType())
----------------
Maybe `IgnoreParens` here too.

================
Comment at: lib/Sema/SemaInit.cpp:3392-3393
@@ -3361,1 +3391,4 @@
+
+  if (Args.size() == 1)
+    CheckMoveOnConstruction(S, Args[0]);
 }
----------------
You should defer the diagnostic until we perform the `InitializationSequence`. We might select a different initialization sequence or overload candidate and not actually call this constructor.

================
Comment at: lib/Sema/SemaStmt.cpp:3049
@@ -3048,1 +3048,3 @@
 
+static void CheckMoveOnReturn(Sema &SemaRef, const Expr *ReturnExpr,
+                              const FunctionDecl *FD) {
----------------
This looks familiar. Can some commonality be factored out here?

Or, better, can you implement both checks in a single place? When performing the initialization sequence, you can ask the initialized entity whether it's the returned object in a return statement.

================
Comment at: lib/Sema/SemaStmt.cpp:3080-3081
@@ +3079,4 @@
+
+  if (!SemaRef.Context.hasSameUnqualifiedType(ReturnType, VD->getType()))
+    return;
+
----------------
If the types don't match, you aren't likely to have a pessimizing move (elision would only occur if your return type's constructor took its argument by value), but perhaps we should still produce some kind of "redundant move" warning. (Per http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579, you get an implicit move no matter what the types are.)

http://reviews.llvm.org/D7633

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/