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.

Reply via email to