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

["glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot 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.