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.