Topic: Temporary elimination (was I need a language lawyer...)


Author: jamshid@ses.com (Jamshid Afshar)
Date: Wed, 10 Nov 1993 23:49:28 GMT
Raw View
In article <1993Nov3.153139.18658@lpi.liant.com>,
Scott Turner <pkt@lpi.liant.com> wrote:
>In article <tjmCFvxzx.4FE@netcom.com>, tjm@netcom.com (Thomas J. Merritt) writes:
>> HugeInt operator-(HugeInt const &l, HugeInt const &r) {
>>     HugeInt t = l;  // 1
>>     t -= r;   // 2
>>     return t;   // 3
>> }
>
>> The question is then, can (&returnvalue == &t) ever be TRUE?
>
>Since your organization is "Code Generation Technology" I'll answer
>as if you are deciding which way to go in implementing a compiler.
>Regardless of the standard, this is an optimization which many users
>want now, and which will help with benchmarks -- every sophisticated
>C++ compiler should have this capability.  The ARM and the C++ standards
>committees' working paper do not explicitly give a green light to this
>optimization.  But the issue has been raised in the committee, and
>discussion indicates that committee members generally consider the
>optimization valid.  There's a good chance that the final standard
>will sanction this return value optimization.

I'm confused because I thought that this optimization is explicitly
allowed by the ARM and WP 12.2.  The ARM 12 commentary even shows a
technique compilers can use to implement this optimization.  Are we
talking about the elimination of a temporary in:

 X f();
 main() {
    X b = f();
 }

The temporary return value, according to the ARM, can be eliminated so
that b is actually constructed inside of f() instead of by a copy-ctor
with the return value of f() as a parameter.  Scott, are you talking
about something else?

The gcc docs definitely seem to be confused about this:

--from gcc 2.5 info page "C++ Dialect Options"--

`-felide-constructors'
     Elide constructors when this seems plausible.  With this option,
     GNU C++ initializes `y' directly from the call to `foo' without
     going through a temporary in the following code:

          A foo ();
          A y = foo ();

     Without this option, GNU C++ (1) initializes `y' by calling the
     appropriate constructor for type `A'; (2) assigns the result of
     `foo' to a temporary; and, finally, (3) replaces the initial value
     of `y' with the temporary.

     The default behavior (`-fno-elide-constructors') is specified by
     the draft ANSI C++ standard.  If your program's constructors have
     side effects, `-felide-constructors' can change your program's
     behavior, since some constructor calls may be omitted.
----

I don't see anything in the ARM or WP which requires
-fno-elide-constructors.  Btw, the optimization doesn't seem to work
even when using -felide-constructors.

Jamshid Afshar
jamshid@ses.com




Author: pkt@lpi.liant.com (Scott Turner)
Date: Fri, 12 Nov 1993 20:05:01 GMT
Raw View
In article <CGAvIH.L4@ses.com>, jamshid@ses.com (Jamshid Afshar) writes:
> In article <1993Nov3.153139.18658@lpi.liant.com>,
> Scott Turner <pkt@lpi.liant.com> wrote:
> >In article <tjmCFvxzx.4FE@netcom.com>, tjm@netcom.com (Thomas J. Merritt) writes:
> >> HugeInt operator-(HugeInt const &l, HugeInt const &r) {
> >>     HugeInt t = l;  // 1
> >>     t -= r;   // 2
> >>     return t;   // 3
> >> }
> >
> >> The question is then, can (&returnvalue == &t) ever be TRUE?
>
> >The ARM and the C++ standards
> >committees' working paper do not explicitly give a green light to this
> >optimization.
>
> I'm confused because I thought that this optimization is explicitly
> allowed by the ARM and WP 12.2.  The ARM 12 commentary even shows a
> technique compilers can use to implement this optimization.

I was ignoring the commentary part of the ARM.  Section 12.2 does not
endorse this optimization, although the ARM's commentary in 12.1.1c does.

> Are we
> talking about the elimination of a temporary in:
>
>  X f();
>  main() {
>     X b = f();
>  }
>
> The temporary return value, according to the ARM, can be eliminated so
> that b is actually constructed inside of f() instead of by a copy-ctor
> with the return value of f() as a parameter.

That's a different optimization, which _is_ mentioned in 12.2.

> The gcc docs definitely seem to be confused about this:

>      The default behavior (`-fno-elide-constructors') is specified by
>      the draft ANSI C++ standard.  If your program's constructors have
>      side effects, `-felide-constructors' can change your program's
>      behavior, since some constructor calls may be omitted.
> ----
>
> I don't see anything in the ARM or WP which requires
> -fno-elide-constructors.  Btw, the optimization doesn't seem to work
> even when using -felide-constructors.

The return value optimization of the first example (and of 12.1.1c) is
a different optimization, at least from a compiler's point of view,
so it's not surprising that -felide-constructors does not influence it.

The gcc doc certainly is confused.  Perhaps it's getting at the fact
that the ARM requires the compiler to check accessibility of the
copy constructor, even if it is elided.  It could be that
-felide-constructors is non-standard because it causes accessibility not
to be checked.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com