Re: optimization/8952: failure to optimize away trivial C++ object creation

Re: optimization/8952: failure to optimize away trivial C++ object creation

[bangerth]

Synopsis: failure to optimize away trivial C++ object creation

State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Fri Dec 20 20:44:33 2002
State-Changed-Why:
    This report is basically superceded by PR 8967.
    
    Thanks, Martin, by the way for actually looking at this,
    although it is so frustrating :-(

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8952

Re: optimization/8952: failure to optimize away trivial C++ object creation

[Andrew Pinski]

The following reply was made to PR optimization/8952; it has been noted by GNATS.

From: Andrew Pinski <pinskia@physics.uc.edu>
To: martin@xemacs.org
Cc: Andrew Pinski <pinskia@physics.uc.edu>, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/8952: failure to optimize away trivial C++ object creation
Date: Sun, 15 Dec 2002 12:31:18 -0800

 The following also does not optimize away on ppc-apple-darwin6.2 also 
 so it does not seems to be target specific.
 
 Thanks,
 Andrew Pinski
 
 >> How-To-Repeat:
 > Compile the following on x86 Linux using: g++ -S -O3
 > examine the .s file generated.
 >
 > class Complex
 > {
 > private:
 >   const int real_;
 >   const int imag_;
 >
 > public:
 >   inline Complex (int real, int imag) : real_ (real), imag_ (imag) {}
 >   inline int Real() const { return real_; }
 >   inline int Imag() const { return imag_; }
 >
 >   inline friend Complex operator+ (Complex z1, Complex z2)
 >   { return Complex (z1.real_ + z2.real_, z1.imag_ + z2.imag_); }
 > };
 >
 > Complex foo () { return Complex(9,11); }
 > Complex bar () { return Complex(1,2) + Complex(8,9); }
 >> Fix:
 >
 >> Release-Note:
 >> Audit-Trail:
 >> Unformatted:
 >
 >
 

optimization/8952: failure to optimize away trivial C++ object creation

[martin]

>Number:         8952
>Category:       optimization
>Synopsis:       failure to optimize away trivial C++ object creation
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 15 12:26:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     martin@xemacs.org
>Release:        gcc-3.2.1
>Organization:
>Environment:
x86 Linux
>Description:
g++ 3.2.1 x86 fails to perform some easy optimizations.  Here I look
at "class literal constant folding".  This might be an important part
of the remaining "abstraction penalty".

Consider this most simple and optimizer-friendly class with 2 data members:


    class Complex
    {
    private:
      const int real_;
      const int imag_;

    public:
      inline Complex (int real, int imag) : real_ (real), imag_ (imag) {}
      inline int Real() const { return real_; }
      inline int Imag() const { return imag_; }

      inline friend Complex operator+ (Complex z1, Complex z2)
      { return Complex (z1.real_ + z2.real_, z1.imag_ + z2.imag_); }
    };


If we now use "Complex Literals" like Complex(3,4), the compiler
should be able to do the obvious optimizations like constant-folding
just as with builtin types.

Now let's look at the x86 assembly code for two functions:

    Complex foo () { return Complex(9,11); }

==>  generates obvious optimal code:

	movl	4(%esp), %eax
	movl	$9, (%eax)
	movl	$11, 4(%eax)
	ret	$4

On the other hand,

    Complex bar () { return Complex(1,2) + Complex(8,9); }

==> generates suboptimal code:

	subl	$20, %esp
	movl	24(%esp), %eax
	movl	$1, 8(%esp)
	movl	$8, (%esp)
	movl	$2, 12(%esp)
	movl	$9, 4(%esp)
	movl	$9, (%eax)
	movl	$11, 4(%eax)
	addl	$20, %esp
	ret	$4


The two functions should generate identical code.  There seem to be
actually too simple optimizer bugs here:

- The addition operand objects above are created, but never used
  (since the result is computed at compile time).  So the code to
  generate them can simply be discarded (the constructors have no side
  effects).

- There seems to be no need to adjust %esp, since this is a leaf function.

Note that these bugs are sufficiently simple that I might be able to
write an easy optimizer pass as a postprocessor on the .s files.

But the gcc maintainers should fix the deeper problems.  Stores to
never-used stack slots should be easy to optimize away.

Could this be part of the reason Intel C++ dramatically outperforms
g++ on Scott Ladd's "Complex" benchmark?

The analogous problem does NOT appear to occur with classes containing
only one data member.

Details: g++ 3.2.1 on Linux x86;  g++ -Wall -S -O3 -fomit-frame-pointer

Disclaimer:  The only assembly code I've ever written was IBM System/370.
>How-To-Repeat:
Compile the following on x86 Linux using: g++ -S -O3
examine the .s file generated.

class Complex
{
private:
  const int real_;
  const int imag_;

public:
  inline Complex (int real, int imag) : real_ (real), imag_ (imag) {}
  inline int Real() const { return real_; }
  inline int Imag() const { return imag_; }

  inline friend Complex operator+ (Complex z1, Complex z2)
  { return Complex (z1.real_ + z2.real_, z1.imag_ + z2.imag_); }
};

Complex foo () { return Complex(9,11); }
Complex bar () { return Complex(1,2) + Complex(8,9); }
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: