This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: elided copy constructors


>>>>> E Robert Tisdale <edwin@netwood.net> writes:

 > Perhaps I shouldn't expect my C++ compiler to elide
 > the copy constructor in function g0(X) if it wasn't inline'd

You are asking it to elide copying a parameter into the return value.  How
would that work?  I suppose, as you suggest, that if g0 is inlined the
caller could figure it out and reuse the argument instead of creating the
return value.  This would require rewriting the gcc inlining code to work
at a higher level, though; inlining is currently done on the basis of RTL,
at which point we've discarded the information we would need.  We've been
talking about making his change for a while, but it's a lot of work.

 > but it I think that the C++ compiler should recognize that x in function
 > f1(int) is a reference to the return value and initialize the return
 > value with X(n) instead of creating a temporary and copying it to the
 > return value upon return from f1(int).

Similarly, this optimization is prevented by the close ties between
frontend and backend; a variable is assigned a memory location when it is
declared, and RTL is generated referring to the stack slot.  We can't
decide to make the local variable cohabit with the return slot until we're
done compiling the function, at which point it's kind of too late to go
back and change all the uses of the variable to use the new location.  This
will be greatly simplified by the planned rewrite to separate the frontends
from the backend more, and not generate RTL until the function is
complete.  I believe the Ada frontend already works this way.

 > My question is, "When should we expect the egcs compiler
 > to elide copy constructors as permitted by the standard?"

When it gets done.  I'd like to see this implemented, too, but haven't had
the time.

 > The class library need not be portable but application programmers
 > should be able to write portable applications without worrying
 > about whether copy constructors are elided or not.

??? If they're worried about portability, they should assume that copy ctors
will not be elided, and plan accordingly.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]