[Bug c++/58055] New: [meta-bug] RVO / NRVO improvements

[Bug c++/58055] New: [meta-bug] RVO / NRVO improvements

[paolo.carlini at oracle dot com]

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

            Bug ID: 58055
           Summary: [meta-bug] RVO / NRVO improvements
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: paolo.carlini at oracle dot com

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-08-02
                 CC|                            |jason at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Adding Jason in CC, I seem to remember he did the ssa implementation.

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[glisse at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glisse at gcc dot gnu.org

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
The various PRs are all fairly similar. Let's see. There are 2 parts to the
optimization: detecting candidate variables, and actually removing the copy and
destruction.

We currently only apply the NRVO when there is a single variable at the topmost
level of the function body such that all return statements are of this
variable. It seems like a wider characterization of the valid cases would be
when we have an automatic variable whose natural lifetime (from the declaration
to the end of the scope) includes returns only of this variable. That may be
easiest to detect in the front-end. Later, the scope would be the try block in
a try-finally right after a constructor call? In SSA it is even less obvious.
For return statements, we need to look for a call to a copy constructor before
a return statement, again more complicated than in the FE.

However, actually performing the optimization in the FE is not trivial.  We
want to remove the calls to the destructor of the variable, but not all, only
those associated to a return. In the cleanup or try-finally forms, there is a
single destructor call, so we can't remove it and we can't mark it as EH-only
since the variable can just go out of scope.  Later, in SSA form (but before
any inlining or it's going to be impossible to find destructor calls), it
should be possible to track which destructor calls to remove. Already in the
front-end, an alternative would be to introduce a boolean at the same time as
the variable, insert a statement setting it to true next to each return of this
variable, and test it in the cleanup/finally code before calling the
destructor. Hopefully the middle-end would optimize this to the same code.

If we don't detect and perform at the same time, we may need to mark the
variables somehow.

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> We currently only apply the NRVO when there is a single variable at the
> topmost level of the function body such that all return statements are of
> this variable. It seems like a wider characterization of the valid cases
> would be when we have an automatic variable whose natural lifetime (from the
> declaration to the end of the scope) includes returns only of this variable.

You can go farther if the return operation overwrites entirely the anonymous
return object and for example allow returning literals, but I don't know if
this is a realistic case in C++; we allow that in Ada.

> That may be easiest to detect in the front-end. Later, the scope would be
> the try block in a try-finally right after a constructor call? In SSA it is
> even less obvious. For return statements, we need to look for a call to a
> copy constructor before a return statement, again more complicated than in
> the FE.

Yes, it's definitely easier to use scoping information in the FE.

> However, actually performing the optimization in the FE is not trivial.  We
> want to remove the calls to the destructor of the variable, but not all,
> only those associated to a return.

In Ada we have little choice but to perform it in the FE, at least for things
like unconstrained array types, because the semantics is lost in the ME.

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #3)
> You can go farther if the return operation overwrites entirely the anonymous
> return object and for example allow returning literals, but I don't know if
> this is a realistic case in C++; we allow that in Ada.

If we build a local object in the return location and later decide to return
another object instead, we need to call the destructor before we overwrite it,
and we end up having to decide if shuffling the function calls that way is
legal (probably hard). That may be ok when the destructor does nothing (the
"literals" you mention?), but my main interest in this optimization in C++ is
cases where the copy constructor and the destructor are non-trivial.

Is there a clever way to chose which literal variables to put in the return
location when there are several candidates (this might require profile
information)? I am also wondering if this version restricted to trivial types
couldn't be done in the middle-end tree-nrv.c.

> In Ada we have little choice but to perform it in the FE, at least for
> things like unconstrained array types, because the semantics is lost in the
> ME.

I was considering a mechanism to tell the middle-end about that semantic, but
it does indeed seem simpler to do everything in the front-end.

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 58051, which changed state.

Bug 58051 Summary: [DR1579] No named return value optimization when returned object is implicitly converted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[marc at kdab dot com]

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

marc at kdab dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc at kdab dot com

--- Comment #5 from marc at kdab dot com ---
I have no clue about the architecture of GCC, but it sounds to me that NRVO is
definitely a front-end optimisation, because it's allowed to change observable
behaviour. E.g., you can elide the copy ctor and dtor even if they have side
effects. Once you go into some intermediate representation, the information
that a set of given side effects can be entirely removed is probably
irrevocably lost.

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 67302, which changed state.

Bug 67302 Summary: [C++14] copy elision in return (expression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67302

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 91217, which changed state.

Bug 91217 Summary: [9 Regression] Returning std::array from lambda results in an extra copy step on return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91217

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 58050, which changed state.

Bug 58050 Summary: No return value optimization when calling static function through unnamed temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58050

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 96004, which changed state.

Bug 96004 Summary: Copy elision with conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96004

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 51571, which changed state.

Bug 51571 Summary: No named return value optimization while adding a dummy scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 58487, which changed state.

Bug 58487 Summary: Missed return value optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug 58055 depends on bug 57176, which changed state.

Bug 57176 Summary: copy elision with function arguments passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176

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