[Bug c++/58055] [meta-bug] RVO / NRVO improvements
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
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
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
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 --- Comment #6 from marc at kdab dot com --- To expand on my previous comment: the compiler is even allowed to elide the copy if that would save a read/write from a volatile object. So I don't see how this can be implemented anywhere except the front-end.
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
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
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
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
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
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
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.
