public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Dan Nicolaescu <dann@ics.uci.edu>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: optimization/6880: Inlining inefficiencies
Date: Sun, 11 May 2003 09:06:00 -0000	[thread overview]
Message-ID: <20030511090601.19113.qmail@sources.redhat.com> (raw)

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

From: Dan Nicolaescu <dann@ics.uci.edu>
To: Dara Hazeghi <dhazeghi@yahoo.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: optimization/6880: Inlining inefficiencies
Date: Sun, 11 May 2003 02:04:06 -0700

 The problem still occurs in mainline CVS. 
 
 But it is not caused by inlining. The problem is the compiler
 generated copy constructor. 
 
 Given the following code:
 
 class Complex {
 public:
     int re, im;
     Complex( int r, int i ) : re(r), im(i) {}
 #ifdef MYCONSTRUCTOR
     Complex( const Complex & F ) : re(F.re), im(F.im) {}
 #endif
     Complex() {}
 };
 
 Complex Yy;
 
 void oop_style()
 {
   Complex factor (53, 37);
   Yy = factor;
 }
 
 The oop_style function is compiled to (on x86):
    
 _Z9oop_stylev:
 .LFB11:
         subl    $12, %esp       #,
 .LCFI0:
         movl    $53, (%esp)     #,                                 
         movl    (%esp), %edx    #, tmp64
         movl    $37, 4(%esp)    #, <variable>.im  
         movl    4(%esp), %ecx   #,                
         movl    %edx, Yy        # tmp64, 
         movl    %ecx, Yy+4      #,
         addl    $12, %esp       #,
         ret
      
 when using g++ -O3   -fverbose-asm -fomit-frame-pointer
        
 and to:
      
 _Z9oop_stylev:
 .LFB14:
         subl    $28, %esp       #,
 .LCFI0:
         movl    $53, %eax       #,
         movl    $37, %edx       #,
         movl    %eax, Yy        #,
         movl    %edx, Yy+4      #,
         addl    $28, %esp       #,
         ret
   
   
 when using g++ -O3 -DMYCONSTRUCTOR  -fverbose-asm -fomit-frame-pointer
   
 Note the extra move to the stack when using the compiler generated
 constructor.
 
 Can the name of the bug be changed to "Inefficient compiler generated
 copy constructor" and be moved to the C++ category? Or should I file
 a new bug report? 
 


             reply	other threads:[~2003-05-11  9:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-11  9:06 Dan Nicolaescu [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-10 23:36 Dara Hazeghi
2002-05-31  0:46 Dan Nicolaescu

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=20030511090601.19113.qmail@sources.redhat.com \
    --to=dann@ics.uci.edu \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@gcc.gnu.org \
    /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).