[Bug c++/102209] New: NRVO for function parameters

["federico.kircheis at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102209

            Bug ID: 102209
           Summary: NRVO for function parameters
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: federico.kircheis at gmail dot com
  Target Milestone: ---

I believe this is a missed optimization opportunity.

Given following class and functions:


----
struct s{ 
   s();
   s(const s&);
   s(s&&);
   void doit();
};

s bar0(){ 
  s v = s();
  v.doit();
  return v;
}
s bar1(s v = s()){
 v.doit(); 
 return v;
}


void foo0(){ auto v = bar0(); }
void foo1(){ auto v = bar1(); }
----

I can see that in bar0, the returned s is copy (and move) elided.
But for bar1, this is not the case.

I've tried different things, like changing function signature, adding
std::forward, change optimization level, disable exceptions, but I was never
able to obtain the desired result.
As in bar1 `v` is actually built a level higher on the stack, for this
code-snippet I would even have expected GCC to have less issue optimizing the
copy/move away.


For reference: https://godbolt.org/z/oe7W3nvcP

foo0():
        sub     rsp, 24
        call    construct()
        lea     rdi, [rsp+15]
        call    s::doit()
        call    destroy()
        add     rsp, 24
        ret
foo1():
        sub     rsp, 24
        call    construct()
        lea     rdi, [rsp+15]
        call    s::doit()
        call    move()
        call    destroy()
        add     rsp, 24
        jmp     destroy()

In both cases, bar* has been inlined.
It can be easily verified that in the case of bar0 everything is inlined, and
no copies are made.
In the case of foo1, a temporary is created, passed to bar without moving or
copying, but when bar1 returns, a move is made.

As s is passed by value, I do not think the move is necessary.
So either my assumption is wrong, or GCC is playing safe.

I would like to know if it is a missed optimization opportunity on the side of
the programmer or compiler (for those classes where even an unnecessary move
might be costly).