public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@cygnus.com>
To: edwin@netwood.net (E. Robert Tisdale)
Cc: egcs@egcs.cygnus.com
Subject: Re: elided copy constructors
Date: Wed, 31 Mar 1999 23:46:00 -0000	[thread overview]
Message-ID: <u9emmk1q3w.fsf@yorick.cygnus.com> (raw)
Message-ID: <19990331234600.0dfnafRTjxFD5D0r8aJ58ghy5f8NOuNRGXJvFRBH1Zs@z> (raw)
In-Reply-To: <36F2CDC1.8B4FEC4A.cygnus.egcs@netwood.net>

>>>>> 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

       reply	other threads:[~1999-03-31 23:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <36F2CDC1.8B4FEC4A.cygnus.egcs@netwood.net>
1999-03-20  1:12 ` Jason Merrill [this message]
1999-03-31 23:46   ` Jason Merrill
1999-03-19 15:37 Timmy Mulligins
1999-03-31 23:46 ` Timmy Mulligins
  -- strict thread matches above, loose matches on Subject: below --
1999-03-19 14:23 E. Robert Tisdale
     [not found] ` < 36F2CDC1.8B4FEC4A@netwood.net >
1999-03-19 15:18   ` Martin v. Loewis
     [not found]     ` < 199903192313.AAA00798@mira.isdn.cs.tu-berlin.de >
1999-03-19 15:54       ` Mark Mitchell
     [not found]         ` < 199903192356.PAA03038@adsl-206-170-148-33.dsl.pacbell.net >
1999-03-19 19:20           ` Tim Hollebeek
1999-03-31 23:46             ` Tim Hollebeek
1999-03-20  6:26           ` espie
     [not found]             ` < 19990320142609.15873.qmail@quatramaran.ens.fr >
1999-03-20  7:18               ` Martin v. Loewis
     [not found]                 ` < 199903201510.QAA08826@mira.isdn.cs.tu-berlin.de >
1999-03-20  9:50                   ` Mark Mitchell
     [not found]                     ` < 199903201752.JAA04517@adsl-206-170-148-33.dsl.pacbell.net >
1999-03-20 11:16                       ` craig
1999-03-31 23:46                         ` craig
1999-03-31 23:46                     ` Mark Mitchell
1999-03-31 23:46                 ` Martin v. Loewis
1999-03-31 23:46             ` espie
1999-03-21  6:09           ` Gerald Pfeifer
1999-03-28  9:45             ` Mark Mitchell
1999-03-29 12:50               ` Gerald Pfeifer
1999-03-31 23:46                 ` Gerald Pfeifer
1999-03-31 23:46               ` Mark Mitchell
1999-03-31 23:46             ` Gerald Pfeifer
1999-03-31 23:46         ` Mark Mitchell
1999-03-31 23:46     ` Martin v. Loewis
1999-03-31 23:46 ` E. Robert Tisdale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=u9emmk1q3w.fsf@yorick.cygnus.com \
    --to=jason@cygnus.com \
    --cc=edwin@netwood.net \
    --cc=egcs@egcs.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).