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).
