Root cause: the temporary variable should not be created if the return value isn't required. This would mean that when the value is not required, preincrement and postincrement are identical, resulting in optimal performance.

Note that the same situation (no return value required) occurs inside comma expressions.

Doesn't the optimizer take care of eliminating the unused temporary and copy?

Thanks, Don!

(In reply to comment #2)
> Doesn't the optimizer take care of eliminating the unused temporary and copy?

Good question. Maybe it does. It sees:
auto t = e, foo(e), t;
Does it know in general that foo() cannot reach t?

BTW -- should the compiler be allowed to eliminate the temporary, if there's a postblit? Ie, is it *forced* to perform the rewrite:

(auto t = e, --e, t)

even if the return value is not used? The optimizer certainly couldn't eliminate it in the general case, but it'd be possible if the front-end is allowed to elide it.

That looks like a very specialized optimization to me. In particular, if the postblit has side effects, the optimizer must have advanced knowledge in order to elide it. This is a path that C++ has taken with copy constructor elision, and it's not a path we should take.

I think the language definition should clarify that postincrement and postdecrement are lowered into their pre- counterparts if the result is not taken.

I was thinking about the code post-inlining.  MOST of the time the operators will be inlined and at that point it should be dead simple for it to eliminate dead stores and thus the temporaries would just go away, no special knowledge or techniques required.  Without inlining, yeah, it can't make assumptions what can occur inside the function calls.

(In reply to comment #6)
> I was thinking about the code post-inlining.  MOST of the time the operators
> will be inlined and at that point it should be dead simple for it to eliminate
> dead stores and thus the temporaries would just go away, no special knowledge
> or techniques required.  Without inlining, yeah, it can't make assumptions what
> can occur inside the function calls.

Inlining is irrelevant. If a this(this) has a writeln() in it, the optimizer must honor it no questions asked. That's why elision must come from a higher level.

(In reply to comment #7)
> Inlining is irrelevant. If a this(this) has a writeln() in it, the optimizer
> must honor it no questions asked. That's why elision must come from a higher
> level.

It's entirely relevant for the original issue: removal of unnecessary temporaries.  Yes, there are opportunities for the language to define away some parts, but that's a separate discussion for a separate bug report.

Bug 3966 is the same as this one. But I'm loathe to mark either as duplicate since 4231 contains useful discussions and 3966 has a vote.

This patch only stops the side effect message, it doesn't turn x++; into ++x;
Note that this patch deals with more difficult cases such as:

struct Foo{
    int opUnary(string op)() { return 1; }
}

void main() {
    Foo foo;
    int w;
    ++w, foo++;
}
----

Index: expression.c
===================================================================
--- expression.c	(revision 526)
+++ expression.c	(working copy)
@@ -8520,6 +8520,14 @@
 
 int CommaExp::checkSideEffect(int flag)
 {
+    // Check for compiler-generated code of the form  auto __tmp, e, __tmp;
+    // In such cases, only check e for side effect (it's OK for __tmp to have no side effect).
+    CommaExp * firstComma = this;
+    while (firstComma->e1->op == TOKcomma)
+        firstComma = (CommaExp *)firstComma->e1;
+    if (firstComma->e1->op == TOKdeclaration && e2->op == TOKvar)
+        return e1->checkSideEffect(flag);
+
     if (flag == 2)
         return e1->checkSideEffect(2) || e2->checkSideEffect(2);
     else

Hrm.. I haven't studied the side effect code enough.  Do you know why Comma:Exp::checkSideEffect isn't just:

return e1->checkSideEffect(flag) || e2->checkSideEffect(flag)

ie, no conditional.

(In reply to comment #11)
> Hrm.. I haven't studied the side effect code enough.  Do you know why
> Comma:Exp::checkSideEffect isn't just:
> 
> return e1->checkSideEffect(flag) || e2->checkSideEffect(flag)
> 
> ie, no conditional.

If flag isn't 2, you still want to check for a useless subexpression.

Eg.
   int x;
   int y;
   ++y, x;
This should still be an error, since x; has no effect.

This shows me that my patch isn't quite right, it will erroneously allow

void main() {
    Foo foo;
    int w;
    foo++, w;
}

--
Revised patch (added one line): should ensure that the created variable is the same as the one which is returned.

    CommaExp * firstComma = this;
    while (firstComma->e1->op == TOKcomma)
        firstComma = (CommaExp *)firstComma->e1;
    if (firstComma->e1->op == TOKdeclaration && e2->op == TOKvar
+        && ((DeclarationExp *)firstComma->e1)->declaration == ((VarExp*)e2)->var)
        return e1->checkSideEffect(flag);

Something about that code bugs me, but I'm having trouble deciding exactly what it is.

Part of it is that there's redundant work.  Move the new code inside the else block?

Part of it is also that it presumes a good bit about the structure of the tree inside a comma expression.  The comment suggests that it can only come from generated code w/in the compiler.  How true is that?  How future proof is it?

Anyway, maybe my subconscious will figure out what's really bugging me while I sleep.  More tomorrow... if anything comes to me.

(In reply to comment #13)
> Something about that code bugs me, but I'm having trouble deciding exactly what
> it is.
> 
> Part of it is that there's redundant work.  Move the new code inside the else
> block?

Although the code in the else block is the same, it's for a very different reason. But I'm not sure it's correct. For example,
int x;
x, ++x;
doesn't raise an error. Yet the first x has no effect!
Shouldn't the part in the else clause be e1->sideeffect() && e2->sideeffect() ?

 
> Part of it is also that it presumes a good bit about the structure of the tree
> inside a comma expression.  The comment suggests that it can only come from
> generated code w/in the compiler.  How true is that?  How future proof is it?

Declarations are not legal inside comma expressions. But the compiler generates them in several places. They are also used in implementing struct constructors and postblit, for example.
There's definitely something a bit weird about the compiler generating code that couldn't get past the parsing stage.

*** Issue 3966 has been marked as a duplicate of this issue. ***

http://www.dsource.org/projects/dmd/changeset/530