[Bug c++/57176] New: copy elision with function arguments passed by value

[Bug c++/57176] New: copy elision with function arguments passed by value

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176

             Bug #: 57176
           Summary: copy elision with function arguments passed by value
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: glisse@gcc.gnu.org


Hello,

it is a well know issue that copy elision is allowed but never implemented in
cases like:

A f(A x){
  return x;
}

and the reason is that the caller and the callee have to communicate for it to
happen. In C, the function would be:
void f_impl(A* ret_p, A* x_p);
with the caller being responsible for allocating space for ret and x and making
the copy into x.

It seems that to make it work, we would need to notice that f is eligible for
this optimization, mark it somehow (indicating which argument can be used as
return value) and clone it:
void f_impl_nrvo(A* ret_x_p);

Callers who would see this mark would instead call the clone with one less
argument.

There are clearly many parts of the front-end I don't understand enough to do
this, but does it look like a correct and workable approach?

[Bug c++/57176] copy elision with function arguments passed by value

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-05-06 12:23:02 UTC ---
Unless I'm misunderstanding your suggestion I think that a compiler is not
allowed to apply copy-elision here, because that case was explicitly excluded
from 12.8 p31 by

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1148
>From gcc-bugs-return-421695-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 06 12:23:11 2013
Return-Path: <gcc-bugs-return-421695-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15488 invoked by alias); 6 May 2013 12:23:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14979 invoked by uid 48); 6 May 2013 12:23:06 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57153] [C++11] tries to use copy constructor for in-class initialized member in default constructor of template struct
Date: Mon, 06 May 2013 12:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Status Last reconfirmed Ever Confirmed
Message-ID: <bug-57153-4-D1iJUqbwbo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57153-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57153-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg00368.txt.bz2
Content-length: 416


http://gcc.gnu.org/bugzilla/show_bug.cgi?idW153

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-05-06
     Ever Confirmed|0                           |1

[Bug c++/57176] copy elision with function arguments passed by value

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> 2013-05-06 12:52:41 UTC ---
(In reply to comment #1)
> Unless I'm misunderstanding your suggestion I think that a compiler is not
> allowed to apply copy-elision here, because that case was explicitly excluded
> from 12.8 p31 by
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1148

Really? Apart from the fact that no compiler implements it so it probably
didn't look like a huge sacrifice at the time, it is in my opinion moving in
the wrong direction (less elision, when we actually need a lot more). Do you
have a link to the discussion, or happen to remember the arguments? I can see
that there are more possible issues with the parameter (it lives a little
longer in the caller, which gives more chances to reuse it), but the permission
to move probably already breaks most such examples.

Thanks for the notice.

[Bug c++/57176] copy elision with function arguments passed by value

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-05-06 13:11:15 UTC ---
(In reply to comment #2)
> Do you have a link to the discussion, or happen to remember the arguments? 
> I can see that there are more possible issues with the parameter (it lives 
> a little longer in the caller, which gives more chances to reuse it), but 
> the permission to move probably already breaks most such examples.

I couldn't find any discussion in regard to this specific issue, but looking at

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#6

it seems that they would prefer to see a paper before the committee would
perform any further action. It seems that inline functions are possibly less
controversial and

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1049

addresses a similar problem in regard to inline functions with reference
parameters.
>From gcc-bugs-return-421698-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 06 13:44:56 2013
Return-Path: <gcc-bugs-return-421698-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7252 invoked by alias); 6 May 2013 13:44:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7211 invoked by uid 48); 6 May 2013 13:44:51 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57176] copy elision with function arguments passed by value
Date: Mon, 06 May 2013 13:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57176-4-WrFpL2auLX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57176-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57176-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg00371.txt.bz2
Content-length: 1563


http://gcc.gnu.org/bugzilla/show_bug.cgi?idW176

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> 2013-05-06 13:44:51 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Do you have a link to the discussion, or happen to remember the arguments?
> > I can see that there are more possible issues with the parameter (it lives
> > a little longer in the caller, which gives more chances to reuse it), but
> > the permission to move probably already breaks most such examples.
>
> I couldn't find any discussion in regard to this specific issue,

I am a bit surprised that handling elision and move differently was obvious
enough not to warrant any discussion (both seem at the same level of risk to me
and mostly differ in implementation difficulty). (Finding something in the
archives of wg21 is hard...)

> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#6
>
> it seems that they would prefer to see a paper before the committee would
> perform any further action. It seems that inline functions are possibly less
> controversial and
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1049
>
> addresses a similar problem in regard to inline functions with reference
> parameters.

Those are BIG changes (that would be great! and a lot of work to implement...),
I was only considering fixing the 1148 clarification. But yeah, that's probably
not going to happen without a paper (not much to write in there...), and
someone at the meeting, and only after C++14 is out, etc.

[Bug c++/57176] copy elision with function arguments passed by value

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2024-03-25

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #2)
> (In reply to comment #1)
> > Unless I'm misunderstanding your suggestion I think that a compiler is not
> > allowed to apply copy-elision here, because that case was explicitly excluded
> > from 12.8 p31 by
> > 
> > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1148
> 
> Really? Apart from the fact that no compiler implements it so it probably
> didn't look like a huge sacrifice at the time, it is in my opinion moving in
> the wrong direction (less elision, when we actually need a lot more).

There have been a lot of changes in the area of copy elision in recent
standards (see links below) but the "other than a function parameter" wording
still remains. So I don't think we can make this optimization without a change
to the standard.

What we are allowed (and even required) to do is treat return values as rvalues
more often, and so perform moves instead of copies. Even if we can't elide that
move entirely, it's better than a copy.

Is it worth keeping this open if we're not allowed to make this change?


Guaranteed copy elision:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html
Implicitly move from rvalue references in return statements / More implicit
moves:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html
Simpler implicit move:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2266r3.html

[Bug c++/57176] copy elision with function arguments passed by value

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #5)
> Is it worth keeping this open if we're not allowed to make this change?

Probably not since wg21 explicitly added text to forbid this optimization. It
belongs in some non-existent wg21 feature request list...